|Summary:||rt61pci doesn't work and oopses on eject on 2.6.20-1.2925.2.5.fc6.netdev.7|
|Product:||[Fedora] Fedora||Reporter:||Vegard Lima <Vegard.Lima>|
|Component:||kernel||Assignee:||John W. Linville <linville>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Brian Brock <bbrock>|
|Version:||rawhide||CC:||anima.salva, ivdoorn, mwallis|
|Fixed In Version:||220.127.116.11-91.fc7||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-10-01 14:17:02 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Vegard Lima 2007-03-21 18:45:34 UTC
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:
Comment 1 Vegard Lima 2007-03-21 18:45:34 UTC
Created attachment 150610 [details] dmesg of oops attached
Comment 3 Vegard Lima 2007-03-22 17:57:18 UTC
All rt2x00 drivers seem to share debug code. And both blow up in debugfs_remove in rt2x00debug_deregister. (I do not have debugfs mounted.)
Comment 4 Vegard Lima 2007-03-31 17:37:04 UTC
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)
Comment 5 Ivo van Doorn 2007-03-31 17:49:13 UTC
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.
Comment 6 Ivo van Doorn 2007-04-08 14:11:17 UTC
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. :(
Comment 7 Vegard Lima 2007-04-08 23:14:46 UTC
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.
Comment 8 Ivo van Doorn 2007-04-09 10:52:56 UTC
The system freeze while interface was up, was this with debugfs disabled? If so could you try to obtain a stacktrace using sysrq?
Comment 9 Vegard Lima 2007-04-09 12:49:13 UTC
Without debugfs, yes: # CONFIG_RT2X00_DEBUGFS is not set. Laptop doesn't respond to Alt+Sysrq when this happens. :(
Comment 10 Ivo van Doorn 2007-04-12 17:42:34 UTC
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.
Comment 11 Vegard Lima 2007-04-13 20:35:36 UTC
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.
Comment 12 Ivo van Doorn 2007-04-14 08:21:53 UTC
Did the freeze you described in comment 7 still present in wireless-dev?
Comment 13 Vegard Lima 2007-04-14 14:21:50 UTC
Yes, the freeze is still there.
Comment 14 Ivo van Doorn 2007-04-14 14:31:55 UTC
Then I don't think this bug should be closed yet. I'll look into the cause of the freeze.
Comment 15 John W. Linville 2007-06-08 13:52:29 UTC
*** Bug 243017 has been marked as a duplicate of this bug. ***
Comment 16 Alessandro 2007-06-17 16:43:29 UTC
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.... :(
Comment 17 Ivo van Doorn 2007-06-19 14:01:30 UTC
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.
Comment 18 John W. Linville 2007-07-16 20:57:46 UTC
Does this problem persist w/ current rawhide kernels (e.g. kernel-2.6.23-0.29.rc0.git6.fc8 or later)?
Comment 19 Vegard Lima 2007-08-07 01:28:30 UTC
Sorry for late reply... Upgraded my laptop to fc7 and tried with 18.104.22.168-41.fc7. I am able to (manually) connect to an accesspoint so there is improvement. The freeze from comment #7 is still there though.
Comment 20 Ivo van Doorn 2007-08-07 18:31:02 UTC
Do you perhaps have a new panic trace of the oops?
Comment 21 Vegard Lima 2007-08-08 02:41:15 UTC
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 (22.214.171.124-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
Comment 22 Ivo van Doorn 2007-08-08 18:43:19 UTC
Thanks that trace is definately helpfull. Was there a particular message above that panic? Something like segmentation fault, Null pointer, or something similar?
Comment 23 Vegard Lima 2007-08-08 23:25:52 UTC
No message before the machine just froze. Had to hit Alt+Sysrq to get the trace.
Comment 24 Ivo van Doorn 2007-08-09 10:13:28 UTC
Ok thanks, the aboce trace should do then. My testing laptop is almost ready for use, so I can try to replicate the bug.
Comment 25 Ivo van Doorn 2007-08-25 13:37:16 UTC
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.
Comment 26 Vegard Lima 2007-09-03 18:38:46 UTC
(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.
Comment 27 Ivo van Doorn 2007-09-16 20:56:43 UTC
Today rt2x00 2.0.8 was released which includes the above mentioned patch.
Comment 28 John W. Linville 2007-09-28 18:52:44 UTC
http://koji.fedoraproject.org/koji/buildinfo?buildID=19787 Do the kernels at the link above work better for you?
Comment 29 Vegard Lima 2007-09-29 02:17:25 UTC
Tried the i686 version of 126.96.36.199-91.fc7. Seems to work, no more oops on eject, able to connect to WEP and WAP networks. Looks good. Thanks.