Hi,
I'm probably missing something obvious, but when going from 3.3 to 3.4
the b43 driver throws up an error, saying it can't find the firmware -
but it really _is_ there.
Here's the error:
b43-phy0 ERROR: Firmware file "b43/ucode16_mimo.fw" not found
b43-phy0 ERROR: Firmware file "b43-open/ucode16_mimo.fw" not found
b43-phy0 ERROR: You must go to
http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and
download the correct firmware for this driver version. Please carefully
read all instructions on this website.
Here's the firmware it claims doesn't exist:
$ sha1sum /lib/firmware/b43/ucode16_mimo.fw
825a4bc63e3a96bb20fd8551add947435d47ad46 /lib/firmware/b43/ucode16_mimo.fw
This is from Debian's firmware-b43-installer package, version 1:015-14.
The network card in question:
02:00.0 Network controller [0280]: Broadcom Corporation BCM4322
802.11a/b/g/n Wireless LAN Controller [14e4:432b] (rev 01)
The only obvious change is 6b6fa5868eec26bdc6a83543cebb8cf832a2645a by
Larry Finger. I don't know if it matters, but b43 is statically compiled
in the kernel.
Am I missing something?
Thanks,
-- Mourad DC
On 05/24/2012 03:25 PM, Larry Finger wrote:
> 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.
Is there no event that you can use to determine when user-space is
available? In the original udev discussion it was suggested to use
IFF_UP, but I did not find anyone saying what the equivalent mac80211
callback should be.
Also this issue can occur when the firmware is only available on the
real root, but the ramdisk contains the b43 module.
Gr. AvS
On 24/05/12 03:13, Larry Finger wrote:
>> The only obvious change is 6b6fa5868eec26bdc6a83543cebb8cf832a2645a
>> by Larry Finger. I don't know if it matters, but b43 is statically
>> compiled in the kernel.
>>
>> Am I missing something?
>
> I do not know. I am building a system with b43 built in. Have you tried
> using b43 as a module?
I just did ? exact same config, just b43 as a module. And indeed, now
the firmware loads fine.
I suppose this isn't intentional? this was working in 3.3, btw.
Thanks,
-- Mourad DC
On 05/24/2012 11:43 AM, Arend van Spriel wrote:
>
> Is there no event that you can use to determine when user-space is
> available? In the original udev discussion it was suggested to use
> IFF_UP, but I did not find anyone saying what the equivalent mac80211
> callback should be.
>
> Also this issue can occur when the firmware is only available on the
> real root, but the ramdisk contains the b43 module.
The callback from request_firmware_nowait() seems to be about as good an
indicator as any.
Yes, having the b43 module in the ramdisk would also cause a problem.
Larry
On 24/05/12 15:25, Larry Finger wrote:
> 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.
Yes, no worries ? I'm perfectly happy with the workaround of using b43
as a module. I just wanted to follow through with it.
> 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.
Yes, I figured as much? but that's why there's testers after all :)
In any case, thank you for your work on this?
Kind regards,
-- Mourad
On 05/23/2012 06:49 PM, Mourad De Clerck wrote:
> Hi,
>
> I'm probably missing something obvious, but when going from 3.3 to 3.4 the b43
> driver throws up an error, saying it can't find the firmware - but it really
> _is_ there.
>
>
> Here's the error:
>
> b43-phy0 ERROR: Firmware file "b43/ucode16_mimo.fw" not found
> b43-phy0 ERROR: Firmware file "b43-open/ucode16_mimo.fw" not found
> b43-phy0 ERROR: You must go to
> http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the
> correct firmware for this driver version. Please carefully read all instructions
> on this website.
>
>
> Here's the firmware it claims doesn't exist:
>
> $ sha1sum /lib/firmware/b43/ucode16_mimo.fw
> 825a4bc63e3a96bb20fd8551add947435d47ad46 /lib/firmware/b43/ucode16_mimo.fw
>
> This is from Debian's firmware-b43-installer package, version 1:015-14.
>
>
> The network card in question:
>
> 02:00.0 Network controller [0280]: Broadcom Corporation BCM4322 802.11a/b/g/n
> Wireless LAN Controller [14e4:432b] (rev 01)
>
>
> The only obvious change is 6b6fa5868eec26bdc6a83543cebb8cf832a2645a by Larry
> Finger. I don't know if it matters, but b43 is statically compiled in the kernel.
>
> Am I missing something?
I do not know. I am building a system with b43 built in. Have you tried using
b43 as a module?
Larry
On 05/23/2012 06:49 PM, Mourad De Clerck wrote:
> Hi,
>
> I'm probably missing something obvious, but when going from 3.3 to 3.4 the b43
> driver throws up an error, saying it can't find the firmware - but it really
> _is_ there.
>
>
> Here's the error:
>
> b43-phy0 ERROR: Firmware file "b43/ucode16_mimo.fw" not found
> b43-phy0 ERROR: Firmware file "b43-open/ucode16_mimo.fw" not found
> b43-phy0 ERROR: You must go to
> http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the
> correct firmware for this driver version. Please carefully read all instructions
> on this website.
>
>
> Here's the firmware it claims doesn't exist:
>
> $ sha1sum /lib/firmware/b43/ucode16_mimo.fw
> 825a4bc63e3a96bb20fd8551add947435d47ad46 /lib/firmware/b43/ucode16_mimo.fw
>
> This is from Debian's firmware-b43-installer package, version 1:015-14.
>
>
> The network card in question:
>
> 02:00.0 Network controller [0280]: Broadcom Corporation BCM4322 802.11a/b/g/n
> Wireless LAN Controller [14e4:432b] (rev 01)
>
>
> The only obvious change is 6b6fa5868eec26bdc6a83543cebb8cf832a2645a by Larry
> Finger. I don't know if it matters, but b43 is statically compiled in the kernel.
I was able to reproduce your result when b43 is built into the kernel, and it
was not intentional. Recent modifications in udev make synchronous firmware
loads fail when the firmware loading is initiated from the probe routine. The
usual solution to switch to asynchronous firmware loading is a poor option for
b43 as it loads multiple firmware files, and the number depends on the model.
Accordingly, I selected a solution that initiates the firmware load from a work
queue. The problem is that user space is not yet started when b43 asks for the
firmware. Such a condition is not needed when b43 is a module as the user-space
routines are started as they are needed to get the module from the disk. I see 2
ways to resolve the problem.
It would be possible to switch to a delayed work queue. I have rejected this
solution for the moment, as the delay would still be there even if the driver
were a module.
The second solution is to make multiple tries of the read of the first firmware
file. If the driver is a module, the first read will succeed, thus there is no
penalty for that case. If the read fails, the code sleeps for 2000 ms, then
retries the read. On my system, the 3rd try works, thus the loop count is set to 10.
Please try the patch below on your system. If it works, please report the number
in the line from the dmesg output that states "********** loop count at exit 2".
Larry
===================================================================
Index: wireless-testing/drivers/net/wireless/b43/main.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -2185,6 +2185,7 @@ static int b43_try_request_fw(struct b43
const char *filename;
u32 tmshigh;
int err;
+ int i;
/* Files for HT and LCN were found by trying one by one */
@@ -2223,9 +2224,18 @@ static int b43_try_request_fw(struct b43
goto err_no_ucode;
}
}
- err = b43_do_request_fw(ctx, filename, &fw->ucode);
+ /* If b43 is builtin rather than as a module, user space will not
+ * be able to supply firmware yet. Retry with a delay
+ */
+ for (i = 0; i < 10; i++) {
+ err = b43_do_request_fw(ctx, filename, &fw->ucode);
+ if (!err)
+ break;
+ msleep(2000);
+ }
if (err)
goto err_load;
+ pr_info("********** loop count at exit %d\n", i);
/* Get PCM code */
if ((rev >= 5) && (rev <= 10))
On 24/05/12 05:03, Larry Finger wrote:
> The second solution is to make multiple tries of the read of the first
> firmware file. If the driver is a module, the first read will succeed,
> thus there is no penalty for that case. If the read fails, the code
> sleeps for 2000 ms, then retries the read. On my system, the 3rd try
> works, thus the loop count is set to 10.
>
> Please try the patch below on your system. If it works, please report
> the number in the line from the dmesg output that states "**********
> loop count at exit 2".
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.
-- M
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