On 05/23/2012 11:38 PM, Mourad De Clerck wrote:
Well, I just tried it. It kinda works, but it seems a bit brittle.
Just after recompiling and rebooting, by chance my system needed a fsck, which
seemed to delay it enough for it to go beyond the loop count, and it failed to
load the firmware.
(Even without the fsck, my laptop could hang around indefinitely in early
userspace waiting for me to type in my cryptoroot password)
Anyway, the second time I rebooted, it was fast enough (without the fsck) to
load the firmware.
dmesg reported "********** loop count at exit 5" in that case.
I was afraid that it might be too fragile; however, after these tests, I have a
solution. Only the first firmware file (ucodeXX.fw) needs to be loaded
asynchronously. Once it is available, all the others can be loaded in a
synchronous manner. Realizing that greatly simplifies the logic.
It may be a while before I sort out all the details of this fix. Until then, you
can use either the temporary fix or compile b43 as a module. To increase the
robustness, change the end of the for loop from "i < 10" to "i < 5000". I could
never do that in final code as it would delay forever if the firmware were
really missing, but it will delay long enough to handle an fsck on root, your
entering of the password for the encrypted fs, or whatever slows the starting of
userland.
I will send you a test patch when the next round is available.
I always have the wireless drivers built as modules. When making changes, one
only needs to recompile, reinstall the new version, and unload/reload the
module. If built into the kernel, a reboot is needed for every change. None the
less, the code needs to handle all cases.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
