From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); it; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1 Description of problem: From when I pass from kernel 2.4.24 to 2.4.25 (and I test all the sub-versions until the latest), I will get (apparently at random) a kernel message to all the consoles that say: 'Disabling IRQ #17' The errors can occurs after 30 minutes, up to 12 hours, or not appears in one day. Most of the time the error comes when I have lot of network traffic (like playing with network game, or updating the system with yum). The problem is that after the network did not work anymore, even if I try to restart the network card. Version-Release number of selected component (if applicable): 2.6.25.11-60.fc8 How reproducible: Sometimes Steps to Reproduce: 1. During normal work but with network activity being done 2. 3. Actual Results: Expected Results: Additional info: Aug 2 11:11:21 localhost kernel: irq 17: nobody cared (try booting with the "irqpoll" option) Aug 2 11:11:21 localhost kernel: Pid: 3952, comm: setiathome-5.28 Tainted: P 2.6.25.11-60.fc8 #1 Aug 2 11:11:21 localhost kernel: Aug 2 11:11:21 localhost kernel: Call Trace: Aug 2 11:11:21 localhost kernel: <IRQ> [<ffffffff81070b23>] __report_bad_irq+0x38/0x7c Aug 2 11:11:21 localhost kernel: [<ffffffff81070d62>] note_interrupt+0x1fb/0x241 Aug 2 11:11:21 localhost kernel: [<ffffffff8107165c>] handle_fasteoi_irq+0xab/0xd0 Aug 2 11:11:21 localhost kernel: [<ffffffff8100e9ad>] do_IRQ+0xf6/0x169 Aug 2 11:11:21 localhost kernel: [<ffffffff8100c371>] ret_from_intr+0x0/0xa Aug 2 11:11:21 localhost kernel: <EOI> Aug 2 11:11:21 localhost kernel: handlers: Aug 2 11:11:21 localhost kernel: [<ffffffff88089886>] (ata_interrupt+0x0/0x1e5 [libata]) Aug 2 11:11:21 localhost kernel: [<ffffffff88396de1>] (azx_interrupt+0x0/0xd1 [snd_hda_intel]) Aug 2 11:11:21 localhost kernel: [<ffffffff882d57ff>] (atl1_intr+0x0/0xbd0 [atl1]) Aug 2 11:11:21 localhost kernel: Disabling IRQ #17 Aug 2 11:11:52 localhost kernel: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Aug 2 11:11:52 localhost kernel: ata5.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0 Aug 2 11:11:52 localhost kernel: cdb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Aug 2 11:11:52 localhost kernel: res 40/00:03:00:08:00/00:00:00:00:00/b0 Emask 0x4 (timeout) Aug 2 11:11:52 localhost kernel: ata5.00: status: { DRDY } Aug 2 11:11:52 localhost kernel: ata5: soft resetting link Aug 2 11:11:53 localhost kernel: ata5.00: configured for UDMA/33 Aug 2 11:11:53 localhost kernel: ata5.01: configured for MWDMA2 Aug 2 11:11:53 localhost kernel: ata5: EH complete more /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 85 1 0 0 IO-APIC-edge timer 1: 2791 1751 5627 2489 IO-APIC-edge i8042 4: 1 0 1 0 IO-APIC-edge 8: 0 0 1 0 IO-APIC-edge rtc 9: 0 0 0 0 IO-APIC-fasteoi acpi 16: 259658 186700 114036 70981 IO-APIC-fasteoi uhci_hcd:usb3, ahci, firewire_ohci, fglrx[0]@PCI:1:0:0 17: 9927 309787 9923 9923 IO-APIC-fasteoi pata_jmicron, HDA Intel, eth0 18: 22676 4991 23097 5210 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8 19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb7 21: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 22: 53373 11202 168871 50731 IO-APIC-fasteoi ata_piix, ata_piix, HDA Intel 23: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6 NMI: 0 0 0 0 Non-maskable interrupts LOC: 6703547 6339294 6519046 6342927 Local timer interrupts RES: 107623 67585 142442 127438 Rescheduling interrupts CAL: 29088 25030 12689 20775 function call interrupts TLB: 850 1208 1404 1617 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts SPU: 0 0 0 0 Spurious interrupts ERR: 0
From one week I'm able to have not the problem manifested again, only if I pass to the kernel the option 'noirqdebug' at boot.
See if adding this line to /etc/sysconfig/network-scripts/ifcfg-eth0 makes the problem go away: ETHTOOL_OPTS="tso off" If so, it's a known bug, which we work around in newer kernels by disabling tso by default. If not, it's probably something new.
With kernel 2.6.25.14-69.fc8, ETHTOOL_OPTS="tso off" and without the option 'noirqdebug' at boot, I have not the error manifested after 3 days of intense use of the PC. I think that the problem is now resolved. Thanks
The workaround should be unnecessary in 2.6.27-based kernels, as it will be the default behavior. We're still working with Atheros to figure out the root cause of the TSO bug, but in the meantime we've gotten NAPI working upstream (should be in F9 soon), with 930 Mbps sustained application-level throughput, so there's less need for TSO.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.