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
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])
apparently unloading and reloading the ath9k module solves the issue
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
the issue seems to be solved with kernel 3.3.4
uhm no, it happened again
Is the same IRQ issue seen on the other PC too ?
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
This bug relates to a very old kernel. Closing as obsolete.