Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at (null); EIP is at rt2x00queue_init_queues+0x4e/0xa0 [rt2x00lib]

ProcModules.txt shows multiple RaLink modules. As a workaround, I've since blacklisted all except rt2860sta in Maverick 10.10 and it seems stable so far.

Lucid 10.04 only loaded rt3090sta, which had no problems once its missing file (bug #541620) was fixed.

I also experience same issue when toggling wifi off-->on-->on (using Fn+F2 on Asus eeepc 1001HA).

Gary, can you please let me know where and how to blacklist the unneeded modules ? In /etc/modprobe.d/blacklist.conf ?
I've identified on my side the following loaded modules:
rt2860sta <-- to keep
rt2800pci
rt2800lib
rt2x00usb
rt2x00pci
rt2x00lib

@Laurent, I've attached a blacklist file which goes into /etc/module.d/ and is named blacklist-wireless.conf

Gary, is there any reason to blacklist rt2800lib, rt2x00usb, rt2x00pci and rt2x00lib? The modinfo for those modules shows no aliases so I think they will only be loaded if a module that lists them as a dependency (e.g. rt2800pci) is loaded.

In this particular case I think the module loading chain goes like this:
lspci.txt:
>02:00.0 Network controller [0280]: RaLink RT3090 Wireless 802.11n 1T/1R PCIe [1814:3090]

modinfo rt2800pci | grep 1814.*3090
>alias: pci:v00001814d00003090sv*sd*bc*sc*i*

modinfo rt2800pci | grep depends
>depends: rt2x00lib,rt2800lib,rt2x00pci,eeprom_93cx6

or am I missing something?

Thanks

An alternative way of doing it would be to use the rt2800pci module and add a script to unload it on shutdown. I've found that the rt2800pci module works better, but sometimes causes the system to freeze when shutting it down, but I added a script in /etc/init.d, and linked it (ln -s) into /etc/rc0.d, and /etc/rc6.d. I've found the module works perfectly then. I then blacklisted rt2860sta.

I can verify Joshua's observation, the rt2800pci is absolutely stable on my HP 4720s and delivers sound 3 Mbyte/sec

There is though a problem with the rt2800pci (at least on my HP 4720s): after a cold restart, it won't see any networks. In order to get it working, I need to load the sta driver, reboot, unload the sta and load the pci driver :-(

Any interesting lines showing up if you do a "grep rt2 /var/log/syslog"?

Hello Wolfgang,

I really lack the expertise to say that... for anyone interested, I'm attaching the output of

grep rt2 /var/log/syslog

@ggonlp

I looked through your log. You said earlier that the rt2800pci was absolutely stable, but these two log lines do suggest otherwise:
phy0 -> rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0.
Please file bug report to http://rt2x00.serialmonkey.com.

Did it stop working before the reboot?

@ggonlp

Oh, I did not want to suggest that you actually file a bug report to serialmonkey. I see now that this looks quite misleading.

What you could do however is try if your problem goes away with the current mainline kernel:
http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/

There might be wireless trouble with the mainline kernel on battery, though. So check while plugged in. Or best try both.

Hello Wolfgang,

Thank you for your answer. From a subjective pov the rt2800pci is stable: I was able to transfer huge files within a local network all day long. If there was a problem with the driver, it didn't lead to dropping the connection.

The sta driver was a completely different story: I had to severely throttle the network connection (via wondershaper) to 30 kb/s, otherwise the WLAN wouldn't last a minute without reconnecting.

Gary M, thank you for reporting this and helping make Ubuntu better. Maverick reached EOL on April 10, 2012.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in a supported release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could 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.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.

Please let us know your results. Thanks in advance.