Description of problem: Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Insert cnet-854 cardbus adapter. 2. iwlist scan doesn't return anything. 3. eject, kernel oopses. Actual results: $iwlist wlan0 scan No scan results. Expected results: With another wireless card: $ /sbin/iwlist eth1 scan eth1 Scan completed : Cell 01 - Address: xx:xx:xx:xx:xx:xx ESSID:"TigerNet" Mode:Master Frequency:2.462 GHz (Channel 11) Signal level:-68 dBm Noise level:-86 dBm Encryption key:on Additional info:
Created attachment 150610 [details] dmesg of oops attached
See also bug 233434...
All rt2x00 drivers seem to share debug code. And both blow up in debugfs_remove in rt2x00debug_deregister. (I do not have debugfs mounted.)
I've also tried 2.6.21-rc5-mm2. The oops goes away if I disable RT2X00_DEBUGFS support, but the card doesn't find anything when scanning with iwlist. Is there some magic needed to get the card going or do I need newer userland tools ? (FC6)
That is a different bug in rt2x00, the radio is not being enabled I know what the problem is that causes that radio problem so I should have that fixed soon.
The correct enabling of the radio bug has been resolved in a patch that has been send to the linux-wireless mailinglist. http://www.spinics.net/lists/linux-wireless/msg01481.html The debugfs problem is still unresolved. :(
Wish I could share your optimism. Applied the patch to 2.6.21-rc5-mm4: iwlist scan works sometimes but the signal strength is waaay lower than with my older card: (-34 dBm vs -170 dBm). The card refuses to associate with any accesspoint. Ejecting the card while the interface wlan0 is up hard freezes the laptop. Ejecting with interface down works fine. Thanks.
The system freeze while interface was up, was this with debugfs disabled? If so could you try to obtain a stacktrace using sysrq?
Without debugfs, yes: # CONFIG_RT2X00_DEBUGFS is not set. Laptop doesn't respond to Alt+Sysrq when this happens. :(
Possible solution to the debugfs bug has been found, rt2x00debug_deregister was called with the reference to debugfs data which was never initialized, but to make matters worse instead of the reference, the reference to the reference was passed. That would be a very valid reason for the kernel to start panicking. ;) The patch has gone into the rt2x00 git tree, I'll send an git-pull request so that the fix will go into wireless-dev and ould move further upstream.
I can confirm that the debugfs bug is gone in the latest wireless-dev tree. ( git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git ) Even though I'm still not able to use the card :( maybe this bug should just be closed.
Did the freeze you described in comment 7 still present in wireless-dev?
Yes, the freeze is still there.
Then I don't think this bug should be closed yet. I'll look into the cause of the freeze.
*** Bug 243017 has been marked as a duplicate of this bug. ***
Any news about this driver? I've the same oopses with an Atlantis card (based on rt61 chipset) and this bug prevent me to use Fedora on laptop.... :(
Latest rt2x00.git contains *a* fix for this, but I have not yet determined if it is the complete fix. At the moment I am preparing an update for wireless-dev kernel which contains this fix, so John can move it into the Fedora kernel.
Does this problem persist w/ current rawhide kernels (e.g. kernel-2.6.23-0.29.rc0.git6.fc8 or later)?
Sorry for late reply... Upgraded my laptop to fc7 and tried with 2.6.22.1-41.fc7. I am able to (manually) connect to an accesspoint so there is improvement. The freeze from comment #7 is still there though.
Do you perhaps have a new panic trace of the oops?
I was able to get the following from Alt+Sysrq (copied from screen): Pid: 0, comm: swapper EIP: 0060:[<e0b14168>] CPU:0 EIP is at rt61pci_interrupt+0x9d/0x202 [rt61pci] EFLAGS: 00000206 Not tainted (2.6.22.1-41.fc7 #1) EAX: e0b20000 EBX: ddfa5f38 ECX: 00000000 EDX: ffffffff ESI: ddfa5f38 EDI: 0004213a EBP: c14c2f00 DS: 007b ES: 007b FS: 00d8 CR0: 8005003b CR2: 001f04b0 CR3: 1fbd4000 CR4: 000006d0 [<c045408a>] handle_IRQ_event+0x1a/0x3f [<c045544a>] handle_level_irq+0x81/0xc7 [<c04553c9>] handle_level_irq+0x0/0xc7 [<c04071f7>] do_IRQ+0xac/0xd1 [<c040592b>] common_interrupt+0x23/0x28 [<c052b201>] acpi_processor_idle+0x21c/0x3df [<c052afe5>] acpi_processor_idle+0x0/0x3df [<c052afe5>] acpi_processor_idle+0x0/0x3df [<c04033c9>] cpu_idle+0x96/0xb7 [<c072aa8e>] start_kernel+0x316/0x31e [<c072a227>] unknown_bootoption+0x0/0x202
Thanks that trace is definately helpfull. Was there a particular message above that panic? Something like segmentation fault, Null pointer, or something similar?
No message before the machine just froze. Had to hit Alt+Sysrq to get the trace.
Ok thanks, the aboce trace should do then. My testing laptop is almost ready for use, so I can try to replicate the bug.
Created attachment 172501 [details] Fix for system freeze on eject I have found a fix for this issue, after this patch I can no longer reproduce this system freeze during eject anymore. I have attached the patch, but the patch will also be present in the rt2x00 2.0.8 release.
(Just noticed your update, didn't get any email) Tried your patch on top of 2.6.23-rc4-mm1, and the oops did go away. Thanks.
Today rt2x00 2.0.8 was released which includes the above mentioned patch.
http://koji.fedoraproject.org/koji/buildinfo?buildID=19787 Do the kernels at the link above work better for you?
Tried the i686 version of 2.6.22.9-91.fc7. Seems to work, no more oops on eject, able to connect to WEP and WAP networks. Looks good. Thanks.