radeon module waiting for radeon-ucode
christopher.howard at frigidcode.com
Wed Nov 14 02:09:25 UTC 2012
On 11/07/2012 01:05 PM, Alexandre Oliva wrote:
> On Nov 7, 2012, Alexey Smirnoff <fling at member.fsf.org> wrote:
> Do you have the radeon module built into the kernel or as a loadable
> Aah! Good to know it's not something I messed up!
> Anyway, let me see if I can help you out.
> I tend to agree ;-)
> Do you happen to know what hotplug script is in effect at the time of
> the request?
> E.g., if this module is built into the kernel, probably none whatsoever
> (in which case it would make sense for the kernel to just abort the
> request right away); if it's loaded early by initrd's init, then you
> gotta make sure the init script configures a hotplug script for the
> kernel to use, and that the hotplug script will let the kernel know if
> it can't find the requested file (looks like it doesn't).
> Even if the hotplug script is configured to wait for some filesystem to
> be mounted or somesuch, you might want to adjust it to recognize
> “/*(DEBLOBBED)*/” as the blob name and fail fast. Depending on how it's
> implemented, even creating a directory named '*(DEBLOBBED)*/' in
> initrd's /lib/firmware might suffice.
> I can't really fix this in GNU Linux-libre, because the whole point of
> keeping the /*(DEBLOBBED)*/ request in place is to signal userland that
> some (non-Free) firmware was requested by a kernel module. I guess I
> could shorten the timeout in reject_firmware, but the timeout is not
> exposed on a per-request basis, so this would require some significant
> improvements to the deblobbing machinery and changes to the firmware
> loading machinery that I'd rather not get into, for I try to keep
> changes WRT upstream to a minimum.
> I hope this helps,
For those of us non-kernel-programmer types, who just want the really
long wait to go away: does someone have a quick and dirty patch we could
apply to our own kernel source?
I use libre kernel through Gentoo's "deblob" USE flag. Gentoo allows
local editing of the source before compiling through dropped in patches
(the epatch_user functionality). And so I was thinking I might be able
to leverage that if I had some kind of patch to work with.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 551 bytes
Desc: OpenPGP digital signature
More information about the linux-libre