firmware loading fails for b43 using linux 3.4?

firmware loading fails for b43 using linux 3.4?

[Mourad De Clerck]

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

Re: firmware loading fails for b43 using linux 3.4?

[Larry Finger]

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

Re: firmware loading fails for b43 using linux 3.4?

[Mourad De Clerck]

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

Re: firmware loading fails for b43 using linux 3.4?

[Larry Finger]

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))

Re: firmware loading fails for b43 using linux 3.4?

[Mourad De Clerck]

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

Re: firmware loading fails for b43 using linux 3.4?

[Larry Finger]

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

Re: firmware loading fails for b43 using linux 3.4?

[Mourad De Clerck]

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

Re: firmware loading fails for b43 using linux 3.4?

[Arend van Spriel]

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

Re: firmware loading fails for b43 using linux 3.4?

[Larry Finger]

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