firmware_loading_store: vmap() failed, broken firmware with kernles .27 - .30

firmware_loading_store: vmap() failed, broken firmware with kernles .27 - .30

[Golden]

Recent compat-wireless releases break firmware loading under slightly older kernels. The bug occurs as tested by me with 2.6.27 and 2.6.30, it does not appear on kernels 2.6.31 and up.

The error log from zd1211rw:

usbcore: registered new interface driver zd1211rw
usb 5-1: firmware: requesting zd1211/zd1211b_ub
compat_firmware 5-1: firmware_loading_store: vmap() failed
usb 5-1: Could not load firmware file zd1211/zd1211b_ub. Error number -2
zd1211rw 5-1:1.0: couldn't load firmware. Error number -2

The error log from b43:

Broadcom 43xx driver loaded [ Features: PMNLS, Firmware-ID: FW13 ]
b43 ssb0:0: firmware: requesting b43/ucode5.fw
compat_firmware ssb0:0: firmware_loading_store: vmap() failed
b43 ssb0:0: firmware: requesting b43-open/ucode5.fw
compat_firmware ssb0:0: firmware_loading_store: unexpected value (0)
b43-phy0 ERROR: Firmware file "b43/ucode5.fw" not found
b43-phy0 ERROR: Firmware file "b43-open/ucode5.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.

To be noted, that compat-wireless releases from December 2009 work fine as well as the kernel's default drivers, every other release from January till now /March/ breaks the firmware loading process, thus the drivers.

If I missed any relevant information, please let me know. 


      

Re: firmware_loading_store: vmap() failed, broken firmware with kernles .27 - .30

[Golden]

The bug, as mentioned above is present in 2.6.30 as well, though with a slightly
different error message, but the with same result - failure.

With latest compat-wiereless versions installed, when the zd1211 dongle is
plugged, an wlanX interface is being initialized, but when 'ifconfig wlanX up'
is issued, the cursor hangs for about 1 minute and driver fails to load the
firmware, despite the fact that the fw is installed and working with the default
kernel drivers and drivers from compat-wireless from December.

LOG:

zd1211rw 5-1:1.0: phy1
usb 5-1: firmware: requesting zd1211/zd1211b_ub
usb 5-1: Could not load firmware file zd1211/zd1211b_ub. Error number -2
zd1211rw 5-1:1.0: couldn't load firmware. Error number -2 

Re: firmware_loading_store: vmap() failed, broken firmware with kernles .27 - .30

[Pavel Roskin]

On Thu, 2010-03-25 at 09:20 -0700, Golden wrote:

> Recent compat-wireless releases break firmware loading under slightly
> older kernels. The bug occurs as tested by me with 2.6.27 and 2.6.30,
> it does not appear on kernels 2.6.31 and up.
...
> b43 ssb0:0: firmware: requesting b43-open/ucode5.fw
> compat_firmware ssb0:0: firmware_loading_store: unexpected value (0)

I was able to reproduce "unexpected value" with Linux 2.6.28.10 and
ar9170usb.

After adding some debug printk's, I get this:

firmware_loading_store: loading = 1
firmware_loading_store: loading = 1
firmware_loading_store: loading = 0
fw_priv->fw->data = ffffc2001027a000
firmware_loading_store: loading = 0
compat_firmware 1-7: firmware_loading_store: unexpected value (0)
firmware_loading_store: abort
usb 1-7: ar9170.fw firmware file not found, trying old firmware...

It looks like we have a race condition here.  Two processes try to load
the firmware.

I remember vaguely that it was discussed before.  Google search for
"firmware_loading_store race" finds some interesting links, but I cannot
find a fix.  Likewise, search for "firmware_loading_store: unexpected
value" finds a lot of stuff in the Linux 2.6.13 timeframe.

It looks like a race condition.  Adding dump_stack() to the beginning of
firmware_loading_store() makes the problem disappear.

-- 
Regards,
Pavel Roskin

Re: firmware_loading_store: vmap() failed, broken firmware with kernles .27 - .30

[Golden]

> I was able to reproduce "unexpected value" with Linux
> 2.6.28.10 and
> ar9170usb.
> 
> After adding some debug printk's, I get this:
> 
> firmware_loading_store: loading = 1
> firmware_loading_store: loading = 1
> firmware_loading_store: loading = 0
> fw_priv->fw->data = ffffc2001027a000
> firmware_loading_store: loading = 0
> compat_firmware 1-7: firmware_loading_store: unexpected
> value (0)
> firmware_loading_store: abort
> usb 1-7: ar9170.fw firmware file not found, trying old
> firmware...
> 
> It looks like we have a race condition here.  Two
> processes try to load
> the firmware.
> 
> I remember vaguely that it was discussed before. 
> Google search for
> "firmware_loading_store race" finds some interesting links,
> but I cannot
> find a fix.  Likewise, search for
> "firmware_loading_store: unexpected
> value" finds a lot of stuff in the Linux 2.6.13 timeframe.
> 
> It looks like a race condition.  Adding dump_stack()
> to the beginning of
> firmware_loading_store() makes the problem disappear.
> 
> -- 
> Regards,
> Pavel Roskin



Hi, Pavel,

This appears to be an important bug fix for a variety of users with older kernels. Can you prepare proper patch for this and did you have a chance to test if these amendments cause trouble with newer kernels? 

Regards.


      

Re: firmware_loading_store: vmap() failed, broken firmware with kernles .27 - .30

[Pavel Roskin]

On Wed, 2010-03-31 at 14:56 -0700, Golden wrote:

> This appears to be an important bug fix for a variety of users with
> older kernels. Can you prepare proper patch for this and did you have
> a chance to test if these amendments cause trouble with newer
> kernels? 

I realize that it's an important issue, but I don't have time to look
for a solution right now.  I did my part by confirming the problem on an
2.6.28.10 kernel.  I don't see it on other kernels, but since it's a
race condition, I cannot say definitely that the same condition cannot
happen on another system running a newer kernel.

-- 
Regards,
Pavel Roskin

Re: firmware_loading_store: vmap() failed, broken firmware with kernles .27 - .30

[Golden]

> I realize that it's an important issue, but I don't have
> time to look
> for a solution right now.  I did my part by confirming
> the problem on an
> 2.6.28.10 kernel.  I don't see it on other kernels,
> but since it's a
> race condition, I cannot say definitely that the same
> condition cannot
> happen on another system running a newer kernel.
> 
> -- 
> Regards,
> Pavel Roskin


Interesting scenario we have here. I confirm the race condition in 2.6.27 and 2.6.30, it appears to be gone in 2.6.31 /Ubuntu 9.10/, it appears to be present in Ubuntu 10.04 /2.6.32/ beta and then it disappears again in 2.6.33 /don't know about .34rc/.

Here's a bug report back from February pertaining to 2.6.32:
https://bugzilla.kernel.org/show_bug.cgi?id=15294