Bug 43173 - Atheros AR9285 performance issue
Atheros AR9285 performance issue
Status: RESOLVED OBSOLETE
Product: Drivers
Classification: Unclassified
Component: network-wireless
All Linux
: P1 normal
Assigned To: drivers_network-wireless@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-28 22:22 UTC by emailadhoc
Modified: 2015-02-19 17:51 UTC (History)
5 users (show)

See Also:
Kernel Version: 3.3.4
Tree: Mainline
Regression: No


Attachments

Description emailadhoc 2012-04-28 22:22:11 UTC
I'm using kernel 2.6.32-220.13.1.el6.x86_64. Everything works fine, but after resumg from ACPI S3 status, i can see that message in dmesg:
 kernel:Disabling IRQ #17

and the wireless connection becomes unstable and very slow.

ping to my access point before suspension: 
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=3.47 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=5.18 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=6.06 ms

and after:
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=8040 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=8139 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=7539 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=7339 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=6440 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=7040 ms

cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       
  0:        130          1          0          1   IO-APIC-edge      timer
  1:        373        502        141        460   IO-APIC-edge      i8042
  8:          1          0          0          0   IO-APIC-edge      rtc0
  9:        638        165        195        166   IO-APIC-fasteoi   acpi
 12:       1643       7982       1497       8379   IO-APIC-edge      i8042
 16:         65        187         79        183   IO-APIC-fasteoi   ehci_hcd:usb1
 17:     156441      14764      14025      14771   IO-APIC-fasteoi   ath9k
Comment 1 emailadhoc 2012-04-29 20:03:39 UTC
Call Trace:
 <IRQ>  [<ffffffff810db5cb>] ? __report_bad_irq+0x2b/0xa0
 [<ffffffff810db7cc>] ? note_interrupt+0x18c/0x1d0
 [<ffffffff810dbeed>] ? handle_fasteoi_irq+0xcd/0xf0
 [<ffffffff8100df09>] ? handle_irq+0x49/0xa0
 [<ffffffff814f520c>] ? do_IRQ+0x6c/0xf0
 [<ffffffff8100ba53>] ? ret_from_intr+0x0/0x11
 <EOI>  [<ffffffff812c4e5e>] ? intel_idle+0xde/0x170
 [<ffffffff812c4e41>] ? intel_idle+0xc1/0x170
 [<ffffffff813fa3f7>] ? cpuidle_idle_call+0xa7/0x140
 [<ffffffff81009e06>] ? cpu_idle+0xb6/0x110
 [<ffffffff814d464a>] ? rest_init+0x7a/0x80
 [<ffffffff81c1ff7b>] ? start_kernel+0x424/0x430
 [<ffffffff81c1f33a>] ? x86_64_start_reservations+0x125/0x129
 [<ffffffff81c1f438>] ? x86_64_start_kernel+0xfa/0x109
handlers:
[<ffffffffa05afdf0>] (ath_isr+0x0/0x190 [ath9k])
Comment 2 emailadhoc 2012-04-29 20:07:21 UTC
apparently unloading and reloading the ath9k module solves the issue
Comment 3 emailadhoc 2012-05-01 01:01:51 UTC
after some time, on another pc with an atheros AR9285 running kernel 3.2.0-2-amd64, here's what happened:

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=11835 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=12464 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=12872 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=12262 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=13147 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=16258 ms
^C
--- 192.168.1.1 ping statistics ---
23 packets transmitted, 6 received, 73% packet loss, time 22123ms
rtt min/avg/max/mdev = 11835.449/13140.227/16258.915/1456.431 ms, pipe 17

reloading the module ath9k solved the issue
Comment 4 emailadhoc 2012-05-02 10:28:47 UTC
the issue seems to be solved with kernel 3.3.4
Comment 5 emailadhoc 2012-05-02 14:37:35 UTC
uhm no, it happened again
Comment 6 Sujith 2012-06-13 15:49:43 UTC
Is the same IRQ issue seen on the other PC too ?
Comment 7 xerofoify 2014-06-25 01:51:36 UTC
I would recommend testing this with a kernel
that was developed in 2014. This is in order
to see if this bug is still valid in 2014.
Thanks Nick
Comment 8 Alan 2015-02-19 17:51:25 UTC
This bug relates to a very old kernel. Closing as obsolete.

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