Bug 39112

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.