Hello, I have a issue with my wireless AR9285 adapter on the new kernel. Everything works fine, until the laptop suspends. After resume, the wireless module is not active anymore. To get it working again I need to do the following: modprobe -r ath9k modprobe ath9k On the older kernel 2.6.38 there was no issue. Hope the problem can be solve, If you need any other info, please contact me.
I have also tried the compat-wireless driver. (Installed fine) No luck.
Can confirm this on 3.0.0-ARCH (Asus K52JT)... Very often (although not 100% of the time), after suspend/resume, the wireless card stops working and the following appears on dmesg: > irq 17: nobody cared (try booting with the "irqpoll" option) > Pid: 0, comm: swapper Tainted: G C 3.0.0-ARCH #1 > Call Trace: > <IRQ> [<ffffffff810c115a>] __report_bad_irq+0x3a/0xd0 > [<ffffffff810c1576>] note_interrupt+0x136/0x1f0 > [<ffffffff810bf669>] handle_irq_event_percpu+0xc9/0x2a0 > [<ffffffff810bf885>] handle_irq_event+0x45/0x70 > [<ffffffff810c1ea7>] handle_fasteoi_irq+0x57/0xd0 > [<ffffffff8100d9f2>] handle_irq+0x22/0x40 > [<ffffffff813f52aa>] do_IRQ+0x5a/0xe0 > [<ffffffff813f2f93>] common_interrupt+0x13/0x13 > <EOI> [<ffffffff813ef94e>] ? schedule+0x34e/0x9f0 > [<ffffffff8127328b>] ? intel_idle+0xcb/0x120 > [<ffffffff8127326d>] ? intel_idle+0xad/0x120 > [<ffffffff81313aad>] cpuidle_idle_call+0x9d/0x350 > [<ffffffff8100a21a>] cpu_idle+0xba/0x100 > [<ffffffff813d0b02>] rest_init+0x96/0xa4 > [<ffffffff81748c23>] start_kernel+0x3de/0x3eb > [<ffffffff81748347>] x86_64_start_reservations+0x132/0x136 > [<ffffffff81748140>] ? early_idt_handlers+0x140/0x140 > [<ffffffff8174844d>] x86_64_start_kernel+0x102/0x111 > handlers: > [<ffffffffa0602e90>] ath_isr > Disabling IRQ #17 The wireless card remains visible in ifconfig/iwconfig, but any operations such as scanning or attempting to connect to a network return no results, until the ath9k module is reinserted. The "irqpoll" option *is* active and has no effect.
Further experimentation reveals that the bug does not appear when running pm-suspend directly, only when using UPower (which, however, runs the same `pm-suspend` script). It seems that this problem is related to whatever UPower is doing before suspend.
Same here, except it happens reliably even with pm-suspend on 3.0-ARCH, 3.1.0-rc2 and 3.1.0-rc1-next-20110812.
Here's some more observations. I added some debugging output to ath_isr and around the call to request_irq in ath_pci_probe. From that it becomes clear that the ath9k interrupt keeps firing while the SC_OP_INVALID flag is set (causing ath_isr not to handle the interrupt). After a couple of milliseconds the IRQ is disabled because of too many unhandled interrupts. The bug also triggers if the ath9k module is insmod'ed only after suspend/resume. The interrupt starts firing right after the call to request_irq in ath_pci_probe. It's also interesting that the bug does _not_ trigger, using the same procedure if networkmanager is running (and is not put to sleep), i.e.: boot, start dbus, start networkmanager, suspend/resume, insmod -> all ok. The bug triggers again, if networkmanager is put to sleep (nmcli nm sleep true), which may explain why suspend via UPower triggers the bug as well. I am attaching dmesg output for two very similar scenarios with different outcome: a) boot, suspend/resume, insmod -> irq 17: nobody cared b) start dbus, start network manager, suspend/resume -> all ok
Created attachment 69532 [details] boot, suspend/resume, modprobe -> irq 17: nobody cared
Created attachment 69542 [details] boot, start dbus, start network manager, suspend/resume, modprobe -> ok
(In reply to comment #6) > Created an attachment (id=69532) [details] > boot, start dbus, start network manager, suspend/resume, modprobe -> irq 17: > nobody cared Grr, that should have been: boot, suspend/resume modprobe -> irq 17: nobody cared.
A patch referencing this bug report has been merged in Linux v3.2-rc1: commit a7d5b76d9a7e434e32a5b2815db45489617dcba6 Author: Clemens Buchacher <drizzd@aon.at> Date: Sat Oct 22 02:56:20 2011 +0000 jme: fix irq storm after suspend/resume
Closing on the basis of comment 9.
I'm having a similar issue, please see #Bug 112351 Thanks.