As stated. But the crash doesn't come immediately. I used to blacklist the rt2500lib module which was in conflict with rt73usb in earlier kernel versions... not about now. How do I confirm it's this card? I used another card which runs the ath9k_htc driver and it runs fine for many many hours, but when I insert and use the (TP-LINK TL-WN321G) rt73usb driver it crashes after sometime, like 30mins - 2hrs. The kernel panic message traceback shows rt7x00lib but i have no idea how to capture that output :(. kernel.log{.1} shows nothing too.
Perhaps you could use netconsole to capture the backtrace? Or if nothing else, attach a digital photo of it?
Is this regression? Does things work in 2.6.37.4 or some other kernel version you had tried before?
I am seeing something similar here. Kernel is 2.6.38.5 and it is quite reproducible. i attach a link to a photo of the kernel hang. http://ballfire.ath.cx/~alex/kernel_oop.jpg Also, i can reproduce it quite well by running this abusive script: #!/bin/bash while (true); do ifdown wlan0 rmmod rt73usb rmmod rt2x00usb modprobe rt73usb modprobe rt2x00usb ifup wlan0 done; At first, it start to fail to localte a wireless DHCP server, and after a pair of new failing attemps to get an IP, the removal of the modules trigger a kernel crash
Created attachment 59992 [details] my rmmod crash
Failing to delete a timer during the rmmod cleanup?
Not sure, but isn't this fixed by the patch "rt2x00: fix rmmod crash" from Stanislaw Gruszka? http://comments.gmane.org/gmane.linux.kernel.wireless.general/71197 It blames 1c0bcf89d85cc97a0d9ce4cd909351a81fa4fdde for the culprit of this bug, but I thought that commit has gone into 3.0 only...
Hellyna, can you test v3.0-rc5 or later?
Comment 3 problem should be fixed by 7f503fc49f144bb509dbd33daf3426df3f176e6b "rt2x00: fix possible memory corruption in case of invalid rxdesc.size". Follow up commit bf4c02d5e772903be5bf8952bac730a2956d0619 "rt2x00: reset usb devices at probe" should prevent some other problems when reloading modules. Both commits are from wireless-testing tree. Perhaps they should be posted to 3.0, but I was a bit worried about possible regression, and do not consider these module reload issues super critical. Not sure if they fix original, crash after few hours problem reported in comment 0. Anyway it's better to test wireless-testing to see if issue is gone.
This bug must be fixed now.