64bit-only: regression: kernels >=2.6.34: rt2800pci: load firmware Error with ralink [1814:0781]

Just tested this:
wolfgang@wolfgang-laptop:~$ uname -a
Linux wolfgang-laptop 2.6.32-02063213-generic #02063213 SMP Mon May 17 11:08:46 UTC 2010 x86_64 GNU/Linux
(ubuntu mainline kernel ppa. compiled for _lucid_)

03:00.0 Network controller: RaLink RT2860
 Subsystem: Foxconn International, Inc. Device e002
 Kernel driver in use: rt2800pci
 Kernel modules: rt2800pci, rt2860sta

compat-wireless-2010-10-25-pc:
filename: /lib/modules/2.6.32-02063213-generic/updates/drivers/net/wireless/rt2x00/rt2800pci.ko

wolfgang@wolfgang-laptop:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=53 time=31.4 ms
(ping went very (25000ms) bad very soon (less than a minute). a problem with compat-wireless-2010-10-25-pc. but that is not the issue here. It loaded the firmware and it connected.)

Just tested the 2.6.36-1.7~lucid1 kernel (natty for lucid from kernel team ppa) on maverick. The rt2800pci (stock from that kernel) produced the load firmware error.

(btw: the rt2860sta of that kernel could not connect to my ad hoc net)

Compiled with debug this is what it says about my chipset in kern.log:
phy0 -> rt2x00_set_chip: Info - Chipset detected - rt: 2872, rf: 0003, rev: 0200.

More testing, this time on lucid with a backported natty kernel:
on lucid (installed) 64bit:
Linux w 2.6.36-1-generic #7~lucid1-Ubuntu SMP Fri Oct 22 00:21:17 UTC 2010 x86_64 GNU/Linux (natty for lucid from kernel team ppa)
can not connect to ad hoc wlan with stock:
03:00.0 Network controller: RaLink RT2860
 Kernel driver in use: rt2860
 Kernel modules: rt2860sta, rt2800pci

blacklist 2860 (with install rt2860sta /bin/false); cold boot; with above kernel; with it's stock rt2800pci:
wolfgang@w:~$ grep -i firmware /var/log/syslog
Oct 29 10:15:22 w kernel: [ 27.070044] phy0 -> rt2800_load_firmware: Error - PBF system register not ready.
Oct 29 10:15:23 w kernel: [ 27.190043] phy0 -> rt2800_load_firmware: Error - PBF system register not ready.

same kernel still:
wolfgang@w:~$ sha256sum /lib/firmware/rt2860.bin
434655ba718eb302720ee1b4b9b9dbf0a16171888ace31ead9f3df2629b9bebb /lib/firmware/rt2860.bin
same as maverick 32 bit, which works

now with compat-wireless-2010-10-25-pc. still on 2.6.36-1-generic #7~lucid1-Ubuntu:
03:00.0 Network controller: RaLink RT2860
 Kernel driver in use: rt2800pci
 Kernel modules: rt2800pci, rt2860sta
Oct 29 12:30:33 w kernel: [ 25.990871] phy0 -> rt2x00lib_request_firmware: Info - Loading firmware file 'rt2860.bin'.
Oct 29 12:30:33 w kernel: [ 26.094709] phy0 -> rt2x00lib_request_firmware: Info - Firmware detected - version: 0.11.
Oct 29 12:30:34 w kernel: [ 26.190084] phy0 -> rt2800_load_firmware: Error - PBF system register not ready.
Oct 29 12:30:34 w kernel: [ 26.320055] phy0 -> rt2800_load_firmware: Error - PBF system register not ready.
(both after putting in the wireless compat modules and after cold boot)
filename: /lib/modules/2.6.36-1-generic/updates/drivers/net/wireless/rt2x00/rt2800pci.ko
license: GPL
firmware: rt2860.bin
description: Ralink RT2800 PCI & PCMCIA Wireless LAN driver.
version: 2.3.0
author: http://rt2x00.serialmonkey.com
srcversion: 9F64E7029DA63951A0E1346

Testing to see what happens on debian:

in summary:
aptosid (debian sid based live CD) with 2.6.35 kernel also shows the load firmware error in 64 bit and does not show that error in 32 bit.

_______
Details, only for reference:
aptosid keres live 64 bit
Linux aptosid 2.6.35-4.slh.9-aptosid-amd64 #1 SMP PREEMPT Mon Sep 13 16:28:34 UTC 2010 x86_64 GNU/Linux
comes with rt2800pci
no rt2860sta in /lib/modules/2.6.35-4.slh.9-aptosid-amd64/kernel/drivers/staging/

did not see firmware load error. not on loading of the stock driver nor after loading the compiled driver. But I did see this after trying to scan with Ceni:
 Oct 31 09:04:00 aptosid kernel: [ 977.437126] rt2800pci 0000:03:00.0: PCI INT A disabled
Oct 31 09:09:06 aptosid kernel: [ 1283.900961] cfg80211: Calling CRDA to update world regulatory domain
Oct 31 09:09:06 aptosid kernel: [ 1283.938498] cfg80211: World regulatory domain updated:
Oct 31 09:09:06 aptosid kernel: [ 1283.938502] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Oct 31 09:09:06 aptosid kernel: [ 1283.938505] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Oct 31 09:09:06 aptosid kernel: [ 1283.938508] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Oct 31 09:09:06 aptosid kernel: [ 1283.938510] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Oct 31 09:09:06 aptosid kernel: [ 1283.938513] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Oct 31 09:09:06 aptosid kernel: [ 1283.938515] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Oct 31 09:09:06 aptosid kernel: [ 1283.954353] rt2800pci 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Oct 31 09:09:06 aptosid kernel: [ 1283.954369] rt2800pci 0000:03:00.0: setting latency timer to 64
Oct 31 09:09:06 aptosid kernel: [ 1283.963501] phy0: Selected rate control algorithm 'minstrel'
Oct 31 09:09:06 aptosid kernel: [ 1283.965839] Registered led device: rt2800pci-phy0::radio
Oct 31 09:09:06 aptosid kernel: [ 1283.966166] Registered led device: rt2800pci-phy0::assoc
Oct 31 09:09:06 aptosid kernel: [ 1283.966568] Registered led device: rt2800pci-phy0::quality
Oct 31 09:15:48 aptosid kernel: [ 1685.122189] phy0 -> rt2x00lib_request_firmware: Error - Failed to request Firmware.

there is no firmware for this in /lib/firmware
copying firmware from maverick:
scan again:
Oct 31 09:33:34 aptosid kernel: [ 2751.018866] phy0 -> rt2800_load_firmware: Error - PBF system register not ready.

interpretation: unlike ubuntu with NetworkManager aptosid keres does not do as much without explicitly being told to. only if I scan does it even try to get firmware. so I have to put firmware in and scan. then i see whether it works. it does not. same problem.

----
cold boot with same CD:
same results with stock rt2800pci. first rt2x00lib_request_firmware: Error - Failed to request Firmware. copying firmware in. rt2800_load_firmware: Error - PBF system register not ready.

---
cold boot with aptosid full's 32 bit kernel:
Linux aptosid 2.6.35-4.slh.9-aptosid-686 #1 SMP PREEMPT Mon Sep 13 16:40:35 UTC 2010 i686 GNU/Linux

Oct 31 10:49:11 aptosid kernel: [ 458.234103] phy0 -> rt2x00lib_requ...

Testing to find with which kernel this problem starts:
In summary:
Last good kernel: Linux w 2.6.33-02063305-generic #02063305 SMP Tue Jun 1 15:08:11 UTC 2010 x86_64 GNU/Linux
First bad kernel: Linux w 2.6.34-020634-generic #020634 SMP Mon May 17 19:27:49 UTC 2010 x86_64 GNU/Linux
both from ubuntu mainline kernels

___________
Details, for reference only:

lucid installed
2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:05:27 UTC 2010 x86_64
compat-wireless-2.6.36-rc5-2-s (self compiled) (rt2800pci)
iperf: 10.9 Mbits/sec

compat-wireless-2010-10-29
has make install fixes
has the 1000+ms ping bug
works on lucid otherwise
does not work on 2.6.36rc8 in maverick.

infrastructure mode with lucid 2.6.32-25 x86_64 and compat wireless compat-wireless-2.6.36-rc5-2-s (self compiled) (rt2800pci)
wolfgang@w:~$ iperf -c ko.local
------------------------------------------------------------
Client connecting to ko.local, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.143 port 46608 connected with 10.0.0.142 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 4.97 MBytes 4.16 Mbits/sec

----
installed lucid:
Linux w 2.6.34-020634-generic #020634 SMP Mon May 17 19:27:49 UTC 2010 x86_64 GNU/Linux from ubuntu mainline kernels
compat-wireless-2.6.36-rc5-2-s
grep rt2 /var/log/syslog
Oct 30 23:20:05 w kernel: [ 548.551467] rt2800pci 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Oct 30 23:20:05 w kernel: [ 548.551482] rt2800pci 0000:03:00.0: setting latency timer to 64
Oct 30 23:20:05 w kernel: [ 548.569974] Registered led device: rt2800pci-phy0::radio
Oct 30 23:20:05 w kernel: [ 548.569994] Registered led device: rt2800pci-phy0::assoc
Oct 30 23:20:05 w kernel: [ 548.570012] Registered led device: rt2800pci-phy0::quality
Oct 30 23:20:05 w NetworkManager: <info> (wlan0): new 802.11 WiFi device (driver: 'rt2800pci')
Oct 30 23:20:05 w kernel: [ 548.579006] rt2800pci 0000:03:00.0: firmware: requesting rt2860.bin
Oct 30 23:20:05 w kernel: [ 548.862556] phy0 -> rt2800_load_firmware: Error - PBF system register not ready.
Oct 30 23:20:05 w kernel: [ 548.960082] phy0 -> rt2800_load_firmware: Error - PBF system register not ready.

installed lucid:
Linux w 2.6.33-02063305-generic #02063305 SMP Tue Jun 1 15:08:11 UTC 2010 x86_64 GNU/Linux
compat-wireless-2.6.36-rc5-2-s
03:00.0 Network controller: RaLink RT2860
 Kernel driver in use: rt2800pci
 Kernel modules: rt2800pci, rt2860sta
works :-) 21.0 Mbits/sec

between the above two it breaks.

Just to make sure I had to try this on an installed 32 bit lucid:
Linux ubu 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010 i686 GNU/Linux
compat-wireless-2.6.36-rc5-2-s
03:00.0 Network controller: RaLink RT2860
 Kernel driver in use: rt2800pci
 Kernel modules: rt2800pci, rt2860sta

As expected this works fine (ad hoc mode).

Just tried the new 2.6.37rc1 32 bit (compiled for maverick) from ubuntu's mainline archive with an installed lucid. The stock rt2800pci connects and transmits data. I however also suffers from rapid ping deterioration (1000+ms).

I am going to undupe this, because I worry it might not be effective to have the more detailed bug report the duplicate.
Also: https://wiki.ubuntu.com/Kernel/Policies/DuplicateBugs

Still, bug #594866 quite likely imho might have the same root cause. It does have all the ingredients from the summary here.

Tried natty desktop live 20101112.1:
64bit shows the load firmware error. 32 bit does not.

Just tried on lucid:
linux-backports-modules-compat-wireless-2.6.35-2.6.32-25-generic_2.6.32-25.24_amd64
This backported rt2800pci works perfectly fine in ad hoc WEP mode (21.3 Mbits/sec with iperf).

Above configuration (comment #12) also works in infrastructure mode with WPA2 (iperf 5Mbit/s).

Hi Wolfgang,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

commit 412b31334b831a8c2909afaca017c5a236ac2dd0
Author: Wolfgang Kufner <email address hidden>
Date: Mon Dec 13 12:39:39 2010 +0100

    rt2x00: Fix firmware loading regression on x86_64.

    Commit 6175ddf06b6172046a329e3abfd9c901a43efd2e changes the way
    memcpy_toio() works for x86_64, causing firmware loading to fail for
    some Ralink WLAN devices with the rt2800pci driver since linux 2.6.34.
    This causes the log message: "phy0 -> rt2800pci_load_firmware: Error -
    PBF system register not ready.".

    Fix this by using __iowrite32_copy instead of memcpy_toio().

    Signed-off-by: Wolfgang Kufner <email address hidden>
    Signed-off-by: Ivo van Doorn <email address hidden>
    Signed-off-by: John W. Linville <email address hidden>

My fix for this firmware loading issue:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=412b31334b831a8c2909afaca017c5a236ac2dd0
along with the the needed preparation patch:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=739fd9405416e22732e46a9226a8cac379bd57fc
is now available via the bleeding edge daily compat-wireless packages.

If you want to know as soon as possible whether this fix does fix your issue too you can compile that compat-wireless package. It is quite easy and takes only a few minutes. Of course you can also wait till the fix comes to you in even more user friendly form, but I do not know how long this will take.
Plus, the sooner you find out that it is not fixed for you, the more time there is to address that before natty comes out.

The long explanations for compat wireless are here:
http://linuxwireless.org/en/users/Download
especially:
http://linuxwireless.org/en/users/Download#Where_to_download_bleeding_edge
http://linuxwireless.org/en/users/Download#Building_and_installing

That is the short version that works for me:
download http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2010-12-14.tar.bz2
extract it with nautilus "extract here"
in a terminal window cd into the extracted directory compat-wireless-2010-12-14
$ ./scripts/driver-select rt2x00
$ make
disable networking via networkManager-applet
remove linux-backports-modules... if you have any installed. They might conflict.
$ sudo modprobe -rv rt2800pci
$ sudo modprobe -rv rt2860sta (if you have that loaded.)
$ sudo make install
$ sudo make unload
$ sudo modprobe -v rt2800pci
enable networking via networkManager-applet
connect

If you can't unload the rt2860sta driver blacklist it and reboot.
If you have blacklisted the rt2... modules you have to undo that before you can load them with modprobe, of course.

Good luck :-)

Thank you for your help Wolfgang!

Doesn't seem to fix the RT3090 here. If I force modprobe to load the rt2800pci or rt2x00pci driver, the card will scan for networks quite happily, but won't establish a connection (WPA encrypted, pre-shared password mode).

If I go back to blacklisting rt2800pci et al, then the (insanely buggy) rt2860sta driver loads, and the card works (more or less) fine, aside from occasionally falling over after a hibernate or suspend cycle.

lspci -v:
02:00.0 Network controller: RaLink RT3090 Wireless 802.11n 1T/1R PCIe
        Subsystem: Micro-Star International Co., Ltd. Device 6891
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at feaf0000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: rt2860
        Kernel modules: rt2800pci, rt2860sta

Hi Phil

Three things:

First, your card scans, so it does not have this bug (firmware loading) anymore, or never had it anyway. Good.

Second, please make doubly sure that only one driver can bind to the card per boot. This might be the source of strange problems from what I have seen.
What I'd do is temporarily rename the module itself:
sudo mv /lib/modules/`uname -r`/kernel/drivers/staging/rt2860/rt2860sta.ko.off /lib/modules/`uname -r`/kernel/drivers/staging/rt2860/rt2860sta.ko.disable
then reboot.
lspci -k should show "Kernel modules: rt2800pci" now, not listing the rt2860sta as a possibility anymore.
Try again.

Third. If it still does not work:
Switch on debugging output in compat wireless. For that in the file config.mk in the compat-wireless folder change the line:
# CONFIG_RT2X00_DEBUG=y
to
CONFIG_RT2X00_DEBUG=y
then compile and install compat wireless again, starting with step ./scripts/driver-select rt2x00.
Unload the old version and load the new (with debugging on).
Try to connect for a while, then plug in a cable and file a new bug with "ubuntu-bug linux" so that we get all the detailed logs that will hopefully allow this bug to be fixed.

Thanks,
Wolfgang

P.S. sudo modprobe -v rt2800pci is right for your hardware, too. rt2x00pci is just a component shared with other drivers, not a driver by itself. It will be pulled in automatically along with a lot of other shared components (about 7 or 8).

OK, I renamed the driver, then rebooted and modprobed rt2800pci. This had the "nice" side-effect of kicking the other laptop off the WiFi, and I couldn't get it to associate.

rmmod -rv rt2800pci followed by modprobe -v rt2860sta got me a Kernel Panic. When the laptop rebooted, the BIOS threw up this warning:

INFO [CHIPSET]: A HyperTransport Sync Flood event was detected on the last boot. Press F1 to continue booting.

Rebooted, renamed rt2860sta back and re-blacklisted rt2800pci, and now my WiFi is working again.

iwlist wlan0 scan:
philpem@ryoko:~$ iwlist wlan0 scan
wlan0 Scan completed :
          Cell 01 - Address: 00:14:BF:9E:46:17
                    Protocol:802.11g
                    ESSID:"Stargate"
                    Mode:Managed
                    Channel:11
                    Quality:100/100 Signal level:-41 dBm Noise level:-83 dBm
                    Encryption key:on
                    Bit Rates:11 Mb/s
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : PSK

Please file a new report by typing ubuntu-bug linux in a terminal window.

>rmmod -rv rt2800pci followed by modprobe -v rt2860sta got me a Kernel Panic.

Did it panic on unloading rt2800pci or on loading rt2860sta?
That sounds a bit like bug 662288. Although there there was an immediate freeze on unload. Anyway, we need a trace of that panic. Maybe comment 15 of bug 662288 can help you get one.

>kicking the other laptop off

Not sure what you mean here.

> Did it panic on unloading rt2800pci or on loading rt2860sta?
> That sounds a bit like bug 662288.

On loading rt2860sta after unloading rt2800pci.

> Anyway, we need a trace of that panic. Maybe comment 15 of bug 662288 can help you get one.

Might be a bit hard when the machine locks solid after the module loads... Serial console would be one option, if this machine had any serial ports...

> >kicking the other laptop off
> Not sure what you mean here.

For as long as the laptop running rt2800pci was powered up (and running rt2800pci), the other laptop sitting across the room couldn't connect to the access point.

You might want to take a look at bug 594866; that's the thread where I originally reported my issues, and exactly describes what was happening with the RT3090 in my MSI U230 netbook. No errors relating to firmware loading, but I can't connect to the WLAN... Load rt2860sta instead (by blacklisting per the bug I listed above), and the card works fine.

OK, so you did see the firmware load error with one kernel. I think what happened on the other was the same phenomenon as I described in bug 662389. Perhaps caused by rebooting instead of a cold start. There is no reason to believe those two almost identical kernels would behave differently with regard to the firmware loading bug.

Please do shutdown - start cycles (not just reboot) when testing wireless. I have reason to believe it does make a difference. It throws all test results into doubt if isn't done. Sorry for not mentioning this earlier.

Mind to give the compat wireless rt2800pci another try, with renaming the other and with shutdown - start? I think it might very well work. After all the driver is reported to work for others for your hardware (Chris in his bug 662288).
Best to recompile compat-wireless with debugging on before, so if it doesn't work you already have good logs to send with ubuntu-bug linux. And _do_ file your own report that way if it doesn't work.

If you also have a "hang on rt2800pci unload bug" (not just a "won't connect bug") then try working around that and then let's make a separate report for that.
There is another report of various hanging (on usb), with the workaround to use ifconcfig wlan0 down to avoid hanging.
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2010-December/002756.html

HTH

Instructions in comment #16 worked for me, thanks Wolfgang!

This is my device, a RT3090 as well, apparently the same as Phil's:

04:00.0 Network controller: RaLink RT3090 Wireless 802.11n 1T/1R PCIe
 Subsystem: Lite-On Communications Inc Device 6632
 Flags: bus master, fast devsel, latency 0, IRQ 17
 Memory at fbff0000 (32-bit, non-prefetchable) [size=64K]
 Capabilities: <access denied>
 Kernel driver in use: rt2800pci
 Kernel modules: rt2800pci, rt2860sta

@Wolfgang:

Looks like both of these patches hit mainline as of 2.6.38-rc1. I'll take a look to see if they can be included in a maverick SRU.

One question about the patches though. In the first patch skb_pad() is called without checking the return value. I'm not all that familiar with the networking code -- is there a reason that we can be sure that the skb_pad() calls will always be successful in this context?

Moving to fix committed for Natty as the patches have hit mainline in v2.6.38. Review and testing is still required for acceptance into Maverick.

Attaching patches for the backport to maverick.

@Wolfgang, I'd appreciate it if you are able to review the patches to
verify that the backport is correct. The first patch didn't apply
cleanly, but I think I hit all the same places that were ultimately
affected by the upstream patch.

I've attached debs for a test build with my backports of Wolfgang's patches. Please let me know whether or not these packages fix the issue.

Hi Seth,

Sorry for the lateish response. Great that you are backporting my patch.

Be aware that I don't have that much C/kernel/WLAN knowledge beyond this patch (my first).

The usb drivers use REGISTER_TIMEOUT32(entry->skb->len), evidently basing the timeout value on the length of the data written. Based on that it would now be REGISTER_TIMEOUT32(entry->skb->len + padding_len). However, that time seems to be rather long already, my beacon e.g. would have a timeout of 11500ms. padding_len would only add a maximum of 375ms. I tried to find some indication of how long that timeout really has to be. It feels like people are using various incarnations of "plenty".

It would have been possible to just backport the beacon padding for the two pci drivers, since only they use the changed register_multiwrite() from the second patch in 2.6.35, so only they need it as preparation for that patch. But the usb beacons should be padded anyway, its nice to have.

Regarding the missing return value check. Good question. No, not sure that it will always be successful. Normal beacons should always have enough tailroom so that skb_pad() does not even have to ask for more memory, but we are not sure that this will always be the case. If an extra long beacon should need to be padded in an out of memory situation skb_pad() might fail, not getting the memory. I tried but could not provoke that. Seems linux does like to give skb_pad() what it asks for even while oom-killing. If it does happen however skb_pad() would free the skb and the call to free it again with dev_kfree_skb_any() produces a hard panic that will leave the user without anything useful to report (unless he already lay in wait before the console with an HD video camera). That, plus seeing that this is checked everywhere else gives me second thoughts, so I am considering proposing a patch upstream (for linux-next). I'd appreciate your thoughts on this issue.

I successfully tried your test kernel with rt2800pci. It now loads the firmware (and also works after that in station mode). Testing against regressions introduced by the padding patch is trickier as it involves four different drivers and this code does only get used in ad hoc mode.

Thanks,
Wolfgang

@Wolfgang:

> The usb drivers use REGISTER_TIMEOUT32(entry->skb->len), evidently
> basing the timeout value on the length of the data written. Based on
> that it would now be REGISTER_TIMEOUT32(entry->skb->len + padding_len).

Yes, I overlooked that, thanks for pointing it out.

> However, that time seems to be rather long already, my beacon e.g. would
> have a timeout of 11500ms. padding_len would only add a maximum of
> 375ms. I tried to find some indication of how long that timeout really
> has to be. It feels like people are using various incarnations of
> "plenty".

That's a long time, but an extra 375ms is insignificant. I guess it
would probably be better to include the extra bytes in the timeout
calculation (if we continue to carry the usb changes, more about that
below).

> It would have been possible to just backport the beacon padding for the
> two pci drivers, since only they use the changed register_multiwrite()
> from the second patch in 2.6.35, so only they need it as preparation for
> that patch. But the usb beacons should be padded anyway, its nice to
> have.

Hmm, that appears to be true. For some reason I thought I had identified
a connection, but looking now that doesn't seem to make sense at all. I
was probably mixing up what I saw in the upstream code with what I saw
in the maverick tree. I'm probably going to strip the usb changes out
then, since this was only reported against pci and as such those changes
are unrelated.

> Regarding the missing return value check. Good question. No, not sure
> that it will always be successful. Normal beacons should always have
> enough tailroom so that skb_pad() does not even have to ask for more
> memory, but we are not sure that this will always be the case. If an
> extra long beacon should need to be padded in an out of memory situation
> skb_pad() might fail, not getting the memory. I tried but could not
> provoke that. Seems linux does like to give skb_pad() what it asks for
> even while oom-killing. If it does happen however skb_pad() would free
> the skb and the call to free it again with dev_kfree_skb_any() produces
> a hard panic that will leave the user without anything useful to report
> (unless he already lay in wait before the console with an HD video
> camera). That, plus seeing that this is checked everywhere else gives me
> second thoughts, so I am considering proposing a patch upstream (for
> linux-next). I'd appreciate your thoughts on this issue.

I'd certainly prefer to see the checks there. I'll add a patch to
introduce the checks when I refresh the series with the other changes.

> I successfully tried your test kernel with rt2800pci. It now loads the
> firmware (and also works after that in station mode). Testing against
> regressions introduced by the padding patch is trickier as it involves
> four different drivers and this code does only get used in ad hoc mode.

Thanks for the review and testing! Agree about the regression testing
being dificult, it frequently is :)

I'll post new patches and test builds as soon as I can get to them,
hopefully later today.

This bug was fixed in the package linux - 2.6.38-1.27

@Wolfgang:

I'm attaching my v2 patches. I added a patch to check the return from
skb_pad(). As part of this I moved the skb padding to the start of each
function, as I would assume we should bail before doing any other device
accesses if we can't get the memory. Let me know whether or not the
behavior looks correct to you.

I've uploaded the test build with these patches to:

  http://people.canonical.com/~sforshee/lp659143/v2/

@Seth

I tested the error path and entry->skb = NULL turns out to be absolutely needed before returning, otherwise there will also be a hard panic.
Moving padding to the start looks good to me. The only thing changing the skb length afterwards is guaranteed to do so by multiples of 32 bits.
Maybe add a full stop at the end of message while you're at it and maybe even an unlikely() if that looks right to you. The other files in the rt2x00 project seem to use it a lot and it does make it nicely explicit that we're not expecting it.

Thanks,
Wolfgang

@Wolfgang:

Thanks again for testing. The unlikely() might make sense. It's actually
a hint to the compiler to allow it to optimize certain code paths that
have an extremely probability of not being taken (90%+ or so), which
would seem to be the case here, although I get the idea that this
particular code is not performance-critical.

I'll fix the missing entry->skb = NULL. I'm also wondering whether there
should be a check that padding_len != 0 to avoid skb_pad() when it's not
needed, because it looks like it assumes that it will be doing some
padding (not that I think there's an actualy bug if padding_len is zero,
just a potential for a significant amount of unnecessary work).

Probably what I ought to do is prepare a patch against mainline and get
some review from the wireless maintainers to answer some of these
lingering questions. I'll plan to do that early next week before I do
any more patches agains maverick.

On Fri, Jan 28, 2011 at 10:10:15PM -0000, Wolfgang Kufner wrote:
> @Seth
>
> I tested the error path and entry->skb = NULL turns out to be absolutely needed before returning, otherwise there will also be a hard panic.
> Moving padding to the start looks good to me. The only thing changing the skb length afterwards is guaranteed to do so by multiples of 32 bits.
> Maybe add a full stop at the end of message while you're at it and maybe even an unlikely() if that looks right to you. The other files in the rt2x00 project seem to use it a lot and it does make it nicely explicit that we're not expecting it.
>
> Thanks,
> Wolfgang
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/659143
>
> Title:
> 64bit-only: regression: kernels >=2.6.34: rt2800pci: load firmware
> Error with ralink [1814:0781]
>
> Status in The Linux Kernel:
> Fix Released
> Status in “linux” package in Ubuntu:
> Fix Released
> Status in “linux” source package in Maverick:
> In Progress
>
> Bug description:
> [UPDATE Dec 16, 2010]
> My fix is in linux-next. See comment 16.
>
> UPSTREAM:
> http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2010-November/002310.html
>
> HARDWARE:
> RaLink RT2860 [1814:0781]
> rt2x00_set_chip: Info - Chipset detected - rt: 2872, rf: 0003, rev: 0200.
>
> SYMPTOM:
> Syslog says: "phy0 -> rt2800pci_load_firmware: Error - PBF system register not ready.".
>
> WLAN does not work at all. The Network Manager Applet says: "Wireless networks disconnected".
> That log entry comes from module rt2800lib which is pulled in by module rt2800pci. (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/wireless/rt2x00/rt2800lib.c;hb=HEAD)
>
> WHERE:
> In summary this happens on all tested ubuntu and debian 64 bit kernels 2.6.34 or newer, but not on 2.6.33 or older. It does however work on fedora's 2.6.35 64 bit live.
>
> POSSIBLE DUPLICATES:
> bug #594866 (ref. comment 10)
>
> WHERE IN DETAIL:
> where it happens:
> In final maverick 64 bit live.
>
> This also happens on the 2.6.36rc8 mainline kernel in a current installed maverick.
> Also happens there with compat-wireless-2010-...

@Seth

> Probably what I ought to do is prepare a patch against mainline and get
> some review from the wireless maintainers to answer some of these
> lingering questions. I'll plan to do that early next week before I do
> any more patches agains maverick.
>
Great. That is best. We want the same solution in mainline and
maverick, after all.

Thanks,
Wolfgang

Okay, looks like we're (finally) close to getting the error handling patch upstream. I'll get maverick SRU patches ready to be submitted as soon as I get the final okay from Ivo.

The error handline patch has been merged into the wireless-next tree.

  http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next-2.6.git;a=commit;h=d76dfc612b40b6a9de0a3fe57fe1fa3db7a1ae3b

I've put up some test builds with all patches backported at the following location for verification.

  http://people.canonical.com/~sforshee/lp659143/saf01/

Please verify that the regression has been fixed and that no obvious new regressions have been introduced.

Thanks!

Attaching v3 of the skb_pad() error checking patch, backported from the version currently in wireless-next.

@Seth

Looks good to go now. Tested your new test build in station mode and ad-hoc mode on my [1814:0781] (rt2800pci).

Thanks,
Wolfgang

SRU Request:

Impact: A regression was introduced between lucid and maverick that
causes firmware loading to fail with the RaLink RT2860 wireless adapter
on amd64.

Fix: The following patches backported from upstream address this issue.
The first two are included in >=2.6.38-rc1, the third is currently in
wireless-next-2.6.

Testcase: Tested by reporter and author of upstream patches (LP
#659143). Without these patches WLAN is not functional with RT2860 on
amd64 kernels. WLAN becomes functional with the patches applied.

Hi
Have installed Pardus 2011 64 bit version and have had no problems with the

RaLink RT2860......

Not being a code writer only a computer user, how come it works OK in Pardus KDE 4.6 ?

perhaps you could look at their code implementation for the problem with the Ralink RT2860

chris

Accepted linux into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Just tested: Bug is fixed in 2.6.35-28-generic #49 from proposed. :-)

@Seth:
There is another severe bug in this driver for rt3090 hardware that we have identified a fix for in linux-next. It looks like it should be cherry-picked for natty. Details in bug 662288. Maybe you could take a look? I'd like to know that it doesn't get overlooked.

Thanks,
Wolfgang

P.S. I have posted a comment (151) to bug 541620 for Andy Whitcroft about this since he asked to test the driver for rt3090 for natty.

@Wolfgang:

Great, glad that we were finally able to get it taken care of! Thanks for all your help.

Andy's the guy to get something into natty, so I'll be sure to bring bug 662288 to his attention.

This bug was fixed in the package linux - 2.6.35-28.49

---------------
linux (2.6.35-28.49) maverick-proposed; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #726796

  [ Colin Ian King ]

  * SAUCE: Dell All-In-One: Remove need for Dell module alias

  [ Manoj Iyer ]

  * SAUCE: add ricoh 0xe823 pci id.
    - LP: #717435

  [ Upstream Kernel Changes ]

  * virtio_net: Add schedule check to napi_enable call
    - LP: #579276
  * mmc: make sdhci work with ricoh mmc controller
    - LP: #717435
  * NFS: fix the return value of nfs_file_fsync()
    - LP: #585657
  * rt2x00: Pad beacon to multiple of 32 bits.
    - LP: #659143
  * rt2x00: Fix firmware loading regression on x86_64.
    - LP: #659143
  * rt2x00: Check for errors from skb_pad() calls
    - LP: #659143
  * block: check for proper length of iov entries earlier in
    blk_rq_map_user_iov(), CVE-2010-4163
    - LP: #721504
    - CVE-2010-4163
  * tty: Make tiocgicount a handler, CVE-2010-4076, CVE-2010-4077
    - LP: #720189
    - CVE-2010-4077
    - CVE-2010-4076
  * rds: Integer overflow in RDS cmsg handling, CVE-2010-4175
    - LP: #721455
    - CVE-2010-4175
 -- Brad Figg <email address hidden> Mon, 28 Feb 2011 13:02:53 -0800

Hello,

It seems that this bug is still not fixed because my kernel (version 2.6.39 but 2.6.38 on natty too) loads a wrong driver for my RT2860 wireless card (rt2800pci instead of rt2860). The crash has been fixed but the it loads the wrong firmare.
It's not a problem for most encryptions used by most wireless networks (e.g. at home) but not for "PEAP with TKIP/MSCHAPv2" or "PEAP-TTLS" encryptions (e.g.: at work or at the university)

Please have a look to this bug report: bug #777215

@Matthieu, your issue is different from the topic of this bug. It belongs on a separate bug report, and since you've already opened a new bug it can be addressed there.

This is back. Using 13.10 64 Bit am having this issue:

[ 5.955844] ieee80211 phy0: rt2800_load_firmware: Error - PBF system register not ready
[ 6.771242] ieee80211 phy0: rt2800_load_firmware: Error - PBF system register not ready
[ 7.574555] ieee80211 phy0: rt2800_load_firmware: Error - PBF system register not ready
[ 8.373910] ieee80211 phy0: rt2800_load_firmware: Error - PBF system register not ready

With a Linksys WMP600n using the rt2800pci module

If I do a workaround mentioned https://bugs.launchpad.net/ubuntu/+source/linux/+bug/673440/comments/8

I get the following error while using the rt2860sta module

ERROR!!! NICLoadFirmware failed, Status[=0x00000001]
!!! rt28xx Initialized fail !!!
NICLoadFirmware: MCU is not ready

Not only that but the whole system becomes very slow. Very VERY slow. If I do a rmmod rt2860sta everything starts to work as normal.

Hello Luis,

Unfortunately, I no longer have this wireless card.
As this bug is fixed, maybe there is another problem.

Feel free to open a new bug report and don't hesitate to indicate that the problem looks the same as this one but with a newer kernel.

Thank you will do that when I get to work. 4 full hours working every
possible scenario and still it did not work. Your bug report is exactly
what is happening. Now my question is, is this only 64 bit?
On Nov 25, 2013 5:21 AM, "Matthieu Baerts" <email address hidden> wrote:

> Hello Luis,
>
> Unfortunately, I no longer have this wireless card.
> As this bug is fixed, maybe there is another problem.
>
> Feel free to open a new bug report and don't hesitate to indicate that
> the problem looks the same as this one but with a newer kernel.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/659143
>
> Title:
> 64bit-only: regression: kernels >=2.6.34: rt2800pci: load firmware
> Error with ralink [1814:0781]
>
> Status in The Linux Kernel:
> Fix Released
> Status in “linux” package in Ubuntu:
> Fix Released
> Status in “linux” source package in Maverick:
> Fix Released
>
> Bug description:
> [UPDATE Dec 16, 2010]
> My fix is in linux-next. See comment 16.
>
> UPSTREAM:
>
> http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2010-November/002310.html
>
> HARDWARE:
> RaLink RT2860 [1814:0781]
> rt2x00_set_chip: Info - Chipset detected - rt: 2872, rf: 0003, rev: 0200.
>
> SYMPTOM:
> Syslog says: "phy0 -> rt2800pci_load_firmware: Error - PBF system
> register not ready.".
>
> WLAN does not work at all. The Network Manager Applet says: "Wireless
> networks disconnected".
> That log entry comes from module rt2800lib which is pulled in by module
> rt2800pci. (
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/wireless/rt2x00/rt2800lib.c;hb=HEAD
> )
>
> WHERE:
> In summary this happens on all tested ubuntu and debian 64 bit kernels
> 2.6.34 or newer, but not on 2.6.33 or older. It does however work on
> fedora's 2.6.35 64 bit live.
>
> POSSIBLE DUPLICATES:
> bug #594866 (ref. comment 10)
>
> WHERE IN DETAIL:
> where it happens:
> In final maverick 64 bit live.
>
> This also happens on the 2.6.36rc8 mainline kernel in a current
> installed maverick.
> Also happens there with compat-wireless-2010-10-20.
>
> Also happens on lucid with a backported natty kernel: (details in
> comment #5)
> on lucid (installed) 64bit:
> Linux w 2.6.36-1-generic #7~lucid1-Ubuntu
> Both with this kernels stock rt2800pci and with self compiled
> compat-wireless-2010-10-25-pc.
>
> Also happens with that 2.6.36-1.7~lucid1 kernel (natty for lucid from
> kernel team ppa) on maverick. The rt2800pci (stock from that kernel)
> produced the load firmware error. (comment #3)
>
> Happens with debian live (aptosid) kernel 2.6.35 64 bit, but not with
> 32bit. (ref. comment 6)
>
> Happens with 2.6.34 (ref. comment 7)
>
> This bug does not happen with:
> not with 2.6.33 (ref. comment 7)
>
> This does not happen on 32 bit maverick live where WLAN works (out of
> the box) just as well as with the rt2860sta.
>
> Does _not_ happen with compat-wireless-2010-10-25-pc on lucid 64bit
> with the standard 2.6.32 kernel. It can connect. (Ping is 1000-25000ms
> though.)
>
> Does _not_ happen wi...

According to Wolfgang, this issue was only affected 64 bits users.
But your problem is certainly not exactly the same as this one.

Thanks friend. Just tested with a live flash drive of ubuntu 13.10 32 bit.
The wifi card works perfectly.

I then installed ubuntu on the pc 32 bit again and it worka out of the box.

The problem is 64bit specific I see.
On Nov 25, 2013 7:56 AM, "Matthieu Baerts" <email address hidden> wrote:

> According to Wolfgang, this issue was only affected 64 bits users.
> But your problem is certainly not exactly the same as this one.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/659143
>
> Title:
> 64bit-only: regression: kernels >=2.6.34: rt2800pci: load firmware
> Error with ralink [1814:0781]
>
> Status in The Linux Kernel:
> Fix Released
> Status in “linux” package in Ubuntu:
> Fix Released
> Status in “linux” source package in Maverick:
> Fix Released
>
> Bug description:
> [UPDATE Dec 16, 2010]
> My fix is in linux-next. See comment 16.
>
> UPSTREAM:
>
> http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2010-November/002310.html
>
> HARDWARE:
> RaLink RT2860 [1814:0781]
> rt2x00_set_chip: Info - Chipset detected - rt: 2872, rf: 0003, rev: 0200.
>
> SYMPTOM:
> Syslog says: "phy0 -> rt2800pci_load_firmware: Error - PBF system
> register not ready.".
>
> WLAN does not work at all. The Network Manager Applet says: "Wireless
> networks disconnected".
> That log entry comes from module rt2800lib which is pulled in by module
> rt2800pci. (
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/wireless/rt2x00/rt2800lib.c;hb=HEAD
> )
>
> WHERE:
> In summary this happens on all tested ubuntu and debian 64 bit kernels
> 2.6.34 or newer, but not on 2.6.33 or older. It does however work on
> fedora's 2.6.35 64 bit live.
>
> POSSIBLE DUPLICATES:
> bug #594866 (ref. comment 10)
>
> WHERE IN DETAIL:
> where it happens:
> In final maverick 64 bit live.
>
> This also happens on the 2.6.36rc8 mainline kernel in a current
> installed maverick.
> Also happens there with compat-wireless-2010-10-20.
>
> Also happens on lucid with a backported natty kernel: (details in
> comment #5)
> on lucid (installed) 64bit:
> Linux w 2.6.36-1-generic #7~lucid1-Ubuntu
> Both with this kernels stock rt2800pci and with self compiled
> compat-wireless-2010-10-25-pc.
>
> Also happens with that 2.6.36-1.7~lucid1 kernel (natty for lucid from
> kernel team ppa) on maverick. The rt2800pci (stock from that kernel)
> produced the load firmware error. (comment #3)
>
> Happens with debian live (aptosid) kernel 2.6.35 64 bit, but not with
> 32bit. (ref. comment 6)
>
> Happens with 2.6.34 (ref. comment 7)
>
> This bug does not happen with:
> not with 2.6.33 (ref. comment 7)
>
> This does not happen on 32 bit maverick live where WLAN works (out of
> the box) just as well as with the rt2860sta.
>
> Does _not_ happen with compat-wireless-2010-10-25-pc on lucid 64bit
> with the standard 2.6.32 kernel. It can connect. (Ping is 1000-25000ms
> though.)
>
> Does _not_ happen with compat-wireless-2010-10-25-pc on maverick
> (2.6.35 kernel) 32 bit live (ping went from good to 1000ms there
...

Annoying :-/
Then don't forget to link your new bug report with this one :-)

Hi.
rt2860sta? That doesn't seem to be shipped with ubuntu anymore.
(and rt28xxpci/lib worked fine last time I checked)

Did test on 5 PCs. 2 had 64 bit. The 2 with 64 bit had problems with
rt2800pci and compiling rt2860sta had the same problem. Now here is the
thing i also tried 32 bit and on 2 pcs it did not work. It started working
after upgrading 3 days ago. Only one worked out of the box. I am writing
from an Android but will post with more info later.

In general 32 works better and 64 does not. But there are still issues in
both environments. Using wmp300n and wmp600n.
On Dec 1, 2013 5:55 PM, "MMlosh" <email address hidden> wrote:

> Hi.
> rt2860sta? That doesn't seem to be shipped with ubuntu anymore.
> (and rt28xxpci/lib worked fine last time I checked)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/659143
>
> Title:
> 64bit-only: regression: kernels >=2.6.34: rt2800pci: load firmware
> Error with ralink [1814:0781]
>
> Status in The Linux Kernel:
> Fix Released
> Status in “linux” package in Ubuntu:
> Fix Released
> Status in “linux” source package in Maverick:
> Fix Released
>
> Bug description:
> [UPDATE Dec 16, 2010]
> My fix is in linux-next. See comment 16.
>
> UPSTREAM:
>
> http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2010-November/002310.html
>
> HARDWARE:
> RaLink RT2860 [1814:0781]
> rt2x00_set_chip: Info - Chipset detected - rt: 2872, rf: 0003, rev: 0200.
>
> SYMPTOM:
> Syslog says: "phy0 -> rt2800pci_load_firmware: Error - PBF system
> register not ready.".
>
> WLAN does not work at all. The Network Manager Applet says: "Wireless
> networks disconnected".
> That log entry comes from module rt2800lib which is pulled in by module
> rt2800pci. (
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/wireless/rt2x00/rt2800lib.c;hb=HEAD
> )
>
> WHERE:
> In summary this happens on all tested ubuntu and debian 64 bit kernels
> 2.6.34 or newer, but not on 2.6.33 or older. It does however work on
> fedora's 2.6.35 64 bit live.
>
> POSSIBLE DUPLICATES:
> bug #594866 (ref. comment 10)
>
> WHERE IN DETAIL:
> where it happens:
> In final maverick 64 bit live.
>
> This also happens on the 2.6.36rc8 mainline kernel in a current
> installed maverick.
> Also happens there with compat-wireless-2010-10-20.
>
> Also happens on lucid with a backported natty kernel: (details in
> comment #5)
> on lucid (installed) 64bit:
> Linux w 2.6.36-1-generic #7~lucid1-Ubuntu
> Both with this kernels stock rt2800pci and with self compiled
> compat-wireless-2010-10-25-pc.
>
> Also happens with that 2.6.36-1.7~lucid1 kernel (natty for lucid from
> kernel team ppa) on maverick. The rt2800pci (stock from that kernel)
> produced the load firmware error. (comment #3)
>
> Happens with debian live (aptosid) kernel 2.6.35 64 bit, but not with
> 32bit. (ref. comment 6)
>
> Happens with 2.6.34 (ref. comment 7)
>
> This bug does not happen with:
> not with 2.6.33 (ref. comment 7)
>
> This does not happen on 32 bit maverick live where WLAN works (out of
> the box) just as well as with the rt2860sta.
>
> Does _not_ happen with compat-wireless-2010-10-25-pc on lucid 6...