Bug 39112 - AR9285 (ath9k) - Asus K52Jc lose wireless module after suspend (Arch/also on Ubuntu)
Summary: AR9285 (ath9k) - Asus K52Jc lose wireless module after suspend (Arch/also on ...
Status: CLOSED CODE_FIX
Alias: None
Product: Networking
Classification: Unclassified
Component: Wireless (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: networking_wireless@kernel-bugs.osdl.org
URL: https://bbs.archlinux.org/viewtopic.p...
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-10 17:53 UTC by beta992
Modified: 2016-02-13 00:53 UTC (History)
7 users (show)

See Also:
Kernel Version: Linux 2.6.39-ARCH #1 SMP PREEMPT Sat Jul 9 14:57:41 CEST 2011 x86_64 GenuineIntel GNU/Linux
Subsystem:
Regression: No
Bisected commit-id:


Attachments
boot, suspend/resume, modprobe -> irq 17: nobody cared (66.14 KB, application/octet-stream)
2011-08-21 12:10 UTC, Clemens Buchacher
Details
boot, start dbus, start network manager, suspend/resume, modprobe -> ok (63.84 KB, application/octet-stream)
2011-08-21 12:10 UTC, Clemens Buchacher
Details

Description beta992 2011-07-10 17:53:49 UTC
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.
Comment 1 beta992 2011-07-10 17:55:55 UTC
I have also tried the compat-wireless driver. (Installed fine)

No luck.
Comment 2 Mantas Mikulėnas 2011-07-24 17:29:34 UTC
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.
Comment 3 Mantas Mikulėnas 2011-07-24 19:24:50 UTC
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.
Comment 4 Clemens Buchacher 2011-08-20 11:59:32 UTC
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.
Comment 5 Clemens Buchacher 2011-08-21 12:08:02 UTC
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
Comment 6 Clemens Buchacher 2011-08-21 12:10:04 UTC
Created attachment 69532 [details]
boot, suspend/resume, modprobe -> irq 17: nobody cared
Comment 7 Clemens Buchacher 2011-08-21 12:10:59 UTC
Created attachment 69542 [details]
boot, start dbus, start network manager, suspend/resume, modprobe -> ok
Comment 8 Clemens Buchacher 2011-08-21 12:12:56 UTC
(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.
Comment 9 Florian Mickler 2012-01-12 21:21:29 UTC
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
Comment 10 John W. Linville 2012-01-13 19:14:00 UTC
Closing on the basis of comment 9.
Comment 11 Diego Viola 2016-02-13 00:53:25 UTC
I'm having a similar issue, please see #Bug 112351

Thanks.

Note You need to log in before you can comment on or make changes to this bug.