rt2x00usb - spontaneous kernel panics

unixfreak · 2011-09-12 23:11:52

Blinking keyboard / complete system freeze is occuring at random times.

I did remove my wireless usb for a while when watching a movie, and the panic did not happen during that time. Though if i leave the computer unattended and connected to the network, it seems to panic at random times.

I managed to find this on the most recent panic:

Sep 11 23:03:45 localhost kernel: [  714.969250] ------------[ cut here ]------------
Sep 11 23:03:45 localhost kernel: [  714.969312] WARNING: at net/mac80211/rc80211_minstrel_ht.c:118 minstrel_ht_tx_status+0x310/0x910 [mac80211]()
Sep 11 23:03:45 localhost kernel: [  714.969318] Hardware name: NQ905AA-ABU CQ5012UK
Sep 11 23:03:45 localhost kernel: [  714.969323] Modules linked in: cryptd aes_x86_64 aes_generic appletalk ipx p8022 psnap llc p8023 ipt_REJECT xt_comment xt_recent ipt_LOG xt_multiport xt_limit xt_tcpudp xt_addrtype xt_state ip6table_filter ip6_tables nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ipv6 nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_realtek arc4 nvidia(P) usb_storage rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib mac80211 cfg80211 uas rfkill keucr(C) snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore sg snd_page_alloc evdev forcedeth edac_core edac_mce_amd k8temp fan i2c_nforce2 thermal i2c_core button cpufreq_ondemand powernow_k8 freq_table processor mperf ext4 mbcache jbd2 crc16 usbhid hid sr_mod cdrom sd_mod pata_acpi ohci_hcd sata_nv libata ehci_hcd scsi_mod usbcore
Sep 11 23:03:45 localhost kernel: [  714.969446] Pid: 308, comm: kworker/u:1 Tainted: P         C  3.0-ARCH #1
Sep 11 23:03:45 localhost kernel: [  714.969451] Call Trace:
Sep 11 23:03:45 localhost kernel: [  714.969472]  [<ffffffff8105c7ef>] warn_slowpath_common+0x7f/0xc0
Sep 11 23:03:45 localhost kernel: [  714.969481]  [<ffffffff8105c84a>] warn_slowpath_null+0x1a/0x20
Sep 11 23:03:45 localhost kernel: [  714.969496]  [<ffffffffa0fff310>] minstrel_ht_tx_status+0x310/0x910 [mac80211]
Sep 11 23:03:45 localhost kernel: [  714.969515]  [<ffffffffa0ff45cf>] ? ieee80211_tx_skb+0x5f/0x70 [mac80211]
Sep 11 23:03:45 localhost kernel: [  714.969531]  [<ffffffffa0fdda49>] ? ieee80211_send_bar+0xd9/0x110 [mac80211]
Sep 11 23:03:45 localhost kernel: [  714.969546]  [<ffffffffa0fd78d3>] ieee80211_tx_status+0x1d3/0x910 [mac80211]
Sep 11 23:03:45 localhost kernel: [  714.969560]  [<ffffffffa0fd7dc9>] ? ieee80211_tx_status+0x6c9/0x910 [mac80211]
Sep 11 23:03:45 localhost kernel: [  714.969573]  [<ffffffffa1019252>] rt2x00lib_txdone+0x1b2/0

Although the other times it has happened, i could not find logs of any kind mentioning a panic had occured. (keyboard lights blinked, so i am assuming a panic did happen). Although since booting up today the computer has been on for at least 3hours now and working absolutely fine.

I'm not really sure whats going on, i was about to recompile the kernel with debugging support for my wireless drivers, though i cannot seem to obtain any kernel sources.... kernel.org is still down, and i cannot seem to find a working mirror. I also cannot find kernel sources on my system or in the archlinux repos??

My wireless device uses the rt2870sta module which was merged with the rt2x00/rt2800 drivers when linux 3.0 was released, i have only been having this problem since then.

uname -a

Linux arch 3.0-ARCH #1 SMP PREEMPT Tue Aug 30 08:53:25 CEST 2011 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ AuthenticAMD GNU/Linux

Any ideas?

clearloon · 2011-09-13 10:15:17

May/may not be related, but I'm having a similar issue with rt2x00/rt61pci since linux 3.0 was released:

https://bbs.archlinux.org/viewtopic.php?id=124989

I haven't found a solution either.

pigiron · 2011-09-13 17:40:37

While you thinking the wireless driver is the problem may turn out to be correct, that warning doesn't positively identify the cause of the panic. But it's certainly not a good sign.

When the kernel panics, all bets are off, but one thing you may try is to turn on "Magic SysRq" to help narrow down the problem.

One way to do this on Arch is to create the following line in /etc/sysctl.conf

kernel.sysrq = 1

followed by a reboot. Then when the panic occurs there are a bunch of commands that can be attempted:

http://www.mjmwired.net/kernel/Documentation/sysrq.txt

Obviously, you may want to print that page to hardcopy first But the "h" command will bring up some terse help text.

Again, while it's not guaranteed that the keyboard will even be active on a kernel panic, I've found it works in many cases.

Keyboards (and and therefore scancodes) differ, but in many cases on a typical USA keyboard, you use the following keystrokes:

Alt + SysRq + "command key"

Press and hold "Alt", then press and hold "SysRq", then press and release the command key, then release the other keys.

One of the more important first commands to enter is the "r" command. This will attempt to grab the keyboard away from X (if you were running X) so that you can then enter any of the other commands without X interference.

But note that my poor memory wants to say that the more you start screwing around with the commands, the more you can taint/destroy the data you're hunting for (for instance the register dumps with the "p" command). I seem to remember that I've had to recreate the problem with no X running (console mode) in order to get a good register dump. Can't remember for sure though.

Anyway, you can try some commands to see if you can narrow down the problem area.

On a related topic; one nice command sequence phrase to remember is:

Reboot Even If System Utterly Broken

The "reisub" sequence will attempt to kill all processes, sync your hard drives, and then reboot. Always a good thing to help prevent trashed hard drives after a panic. Just one reason I always have SysRq turned on.

To be complete though, I should mention that having SysRq on is a security risk; someone can walk up to your box and bring it down without a login or password.

Lastly... in the worst case, setting up the kernel debugger would be another option... but a painful one.

Last edited by pigiron (2011-09-13 18:40:15)

unixfreak · 2011-09-14 05:54:06

Thanks for the information, i will try that if it happens again. If i enable sysrq is it safe to use if i am the only person with physical access to the computer?

Since yesterday i have compiled a new kernel (linux-fbcondecor from the aur) with some modified options, although i did get another panic in the evening while watching a film with VLC. I did notice at the time i was running ktorrent to seed several iso images... come to think of it, a panic has happened only when ktorrent was running.

Is it possible i am receiving malformed packets from a peer in the torrent swarm, could this cause a kernel panic?

Here is my daemon array from rc.conf if its of any interest:

DAEMONS=(hwclock syslog-ng preload fbcondecor dbus ufw @wicd @crond @sshd @alsa @cpufreq @gpm)

I guess if it continues, and i can't find out the cause i will try using the rt2870usb package from the aur, and disable the rt2x00 module from my kernel config.

ewaller · 2011-09-14 06:46:47

pigiron wrote:

...When the kernel panics, all bets are off, but one thing you may try is to turn on "Magic SysRq" to help narrow down the problem....Again, while it's not guaranteed that the keyboard will even be active on a kernel panic, I've found it works in many cases.

The Magic SysRq works great if the kernel is hung in a race condition and is non-responsive.
Once it panics, it's game over -- it's pining for the fjords. A flashing keyboard indicator is indicative of a kernel that has panicked and has thrown in the towel. Magic Sysrq can't help you at that point.

Last edited by ewaller (2011-09-14 06:47:31)

unixfreak · 2011-09-14 09:33:21

ewaller wrote:

A flashing keyboard indicator is indicative of a kernel that has panicked and has thrown in the towel.

Would that be the reason i don't seem to get any output in logfiles at times? Suggesting that the whole system is borked before it can even write to the logs about the problem?

ewaller · 2011-09-14 14:51:12

Yes. A kernel panic is the equivalent of the infamous "Blue Screen of Death" from that OS from the US Pacific Northwest. It occurs when the kernel is so confused, it enters a safe state from which there is no escape short of a hardware reset. This is the most severe form of error. Other errors, it tries to deal with -- unsolicited interrupts for which it cannot find a source, for example. Other, less severe things might cause the kernel to declare itself as tainted and disable certain things. These sorts of errors find their way to the logs.

A kernel panic is so severe, that the developer who wrote the code is concerned about the kernel doing something dangerous or destructive. One possible condition for this might memory management exception for an instruction fetch whilst running kernel code. In user space, that would cause an segmentation fault. If you are in kernel (trusted) space, and you get lost in memory, it probably is best to just stop rather than make things worse. Writes to disk are out of the question.

Last edited by ewaller (2011-09-14 14:52:01)

Arch Linux

#1 2011-09-12 23:11:52

rt2x00usb - spontaneous kernel panics

#2 2011-09-13 10:15:17

Re: rt2x00usb - spontaneous kernel panics

#3 2011-09-13 17:40:37

Re: rt2x00usb - spontaneous kernel panics

#4 2011-09-14 05:54:06

Re: rt2x00usb - spontaneous kernel panics

#5 2011-09-14 06:46:47

Re: rt2x00usb - spontaneous kernel panics

#6 2011-09-14 09:33:21

Re: rt2x00usb - spontaneous kernel panics

#7 2011-09-14 14:51:12

Re: rt2x00usb - spontaneous kernel panics

Board footer