radeon module waiting for radeon-ucode

[Christopher Howard]

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
> module?
> 
> 
> 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.

-- 
frigidcode.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20121113/914bf3bc/attachment.pgp>