User: Password:
Subscribe / Log in / New account

Firmware loading and suspend/resume

Firmware loading and suspend/resume

Posted Sep 20, 2012 23:19 UTC (Thu) by iive (guest, #59638)
Parent article: Firmware loading and suspend/resume

There might be a(nother) case where this new mechanism won't work.

If you attach USB device while the system is suspended, on resume the usb-core would find it and probe a driver for it. That driver would try to load a firmware, but because it have never been loaded before it won't be found in the "cache".

Honestly, why is userland even involved in firmware loading? The whole userland shenanigan should be scraped and reverted to the old system where the kernel loads the firmware directly from the filesystem. If the kernel modules are accessible, then the firmware would be accessible too. (Use tmpfs or initrd as workarounds for the other cases.)


(Log in to post comments)

Firmware loading and suspend/resume

Posted Sep 21, 2012 22:49 UTC (Fri) by nix (subscriber, #2304) [Link]

I pretty much concur. The userspace loader causes problems even when it isn't being used at all. e.g. I just got a new machine with a Barts GPU in it (ATI Radeon 6870), and since I have a largely non-modular kernel with KMS built in I put all the firmware I thought it would need into CONFIG_EXTRA_FIRMWARE. I forgot one file... so the system hung for something like sixty seconds(!) trying to call out to userspace to load the firmware -- even though PID 1 had not yet been forked off! Of course because this was brand-new hardware and it was right at modesetting time I thought I'd messed something up in the .config or there was something major missing in the kernel's KMS support or something like that.

The whole thing is a complete trainwreck, from the need to dig through source code to find the right names to jam in CONFIG_EXTRA_FIRMWARE through the userspace loading that you can use except in unusual situations such as if you have even a single firmware-using module built into the kernel or if you need even a single firmware-using module to resume from hibernation. (Oh, and how much assistance does the kernel give you in detecting that you have either of those situations? None, that's how much. It just dies without a message at the appropriate time. IIRC there's been talk about fixing the hibernation side of this, but I don't think anything ever came of it.)

This whole thing was designed entirely to let distro vendors produce something without violating the GPL, and it does that -- but unfortunately it makes it bloody hard for the rest of us to produce working systems without digging through the source code if we have anything needing firmware at all, even if we're not using modules for anything.

(Sorry, Matthew, I really don't like to criticise your work -- but this banjaxed-up firmware-loading mess just wasted several hours of my time hunting for a 'lockup' that wasn't, due to a hugely overlong timeout that even the stupidest kernel should not have incurred, on a kernel with no loadable firmware of any sort, before userspace was even running. This is not something that has been tested in the non-modular case with an eye to not being intolerably awful.)

Firmware loading and suspend/resume

Posted Sep 22, 2012 13:33 UTC (Sat) by jackb (guest, #41909) [Link]

Another cool feature is that if you are trying to build a non-modular driver that requires firmware that's included in the kernel sources, and have KBUILD_OUTPUT set compilation will fail due to a "not found" error until you manually copy the firmware directory to $KBUILD_OUTPUT

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds