Hide Forgot
Description of problem: Whenever I use my D-Link card on my Asus P8H 61-MLE/CSM motherboard the kernel will eventually effectively disable it by ignoring the associated interrupt with a complaint about have received an interrupt nobody cared about. I have tried booting with the 'irqpoll' option, but it has no effect. Version-Release number of selected component (if applicable): kernel-2.6.40.3-0.fc15.x86_64 How reproducible: It happens randomly, sometimes as soon as 4 minutes after boot, and sometimes as long as 10 hours after boot. Steps to Reproduce: 1.Configure the D-Link card to be up and accepting packets 2.wait Actual results: kernel eventually disables the interrupt associated with the card Expected results: That it runs fine for an arbitrary length of time Additional info: Here is the lspci -v info for the card: 07:00.0 Ethernet controller: D-Link System Inc DGE-530T Gigabit Ethernet Adapter (rev 11) (rev 11) Subsystem: D-Link System Inc DGE-530T Gigabit Ethernet Adapter (rev 11) Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at fe420000 (32-bit, non-prefetchable) [size=16K] I/O ports at d000 [size=256] Expansion ROM at fe400000 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Kernel driver in use: skge Kernel modules: skge Here is the /var/log/messages log of events leading up to the disabling of the interrupt: Aug 21 12:14:45 dark kernel: [ 3159.289490] irq 16: nobody cared (try booting with the "irqpoll" option) Aug 21 12:14:45 dark kernel: [ 3159.289520] Pid: 0, comm: swapper Not tainted 2.6.40.3-0.fc15.x86_64 #1 Aug 21 12:14:45 dark kernel: [ 3159.289521] Call Trace: Aug 21 12:14:45 dark kernel: [ 3159.289522] <IRQ> [<ffffffff810af6fc>] __report_bad_irq+0x38/0xc3 Aug 21 12:14:45 dark kernel: [ 3159.289529] [<ffffffff810af993>] note_interrupt+0x173/0x1f0 Aug 21 12:14:45 dark kernel: [ 3159.289531] [<ffffffff810adfca>] handle_irq_event_percpu+0x15d/0x1a5 Aug 21 12:14:45 dark kernel: [ 3159.289533] [<ffffffff810ae04a>] handle_irq_event+0x38/0x56 Aug 21 12:14:45 dark kernel: [ 3159.289536] [<ffffffff810753a8>] ? sched_clock_cpu+0x42/0xc6 Aug 21 12:14:45 dark kernel: [ 3159.289538] [<ffffffff810b0132>] handle_fasteoi_irq+0x77/0x9b Aug 21 12:14:45 dark kernel: [ 3159.289541] [<ffffffff8100ab6d>] handle_irq+0x88/0x8e Aug 21 12:14:45 dark kernel: [ 3159.289543] [<ffffffff8148fbdd>] do_IRQ+0x4d/0xa5 Aug 21 12:14:45 dark kernel: [ 3159.289547] [<ffffffff81487dd3>] common_interrupt+0x13/0x13 Aug 21 12:14:45 dark kernel: [ 3159.289548] <EOI> [<ffffffff8100e969>] ? paravirt_read_tsc+0x9/0xd Aug 21 12:14:45 dark kernel: [ 3159.289553] [<ffffffff81283fa0>] ? intel_idle+0xd8/0x100 Aug 21 12:14:45 dark kernel: [ 3159.289554] [<ffffffff81283f82>] ? intel_idle+0xba/0x100 Aug 21 12:14:45 dark kernel: [ 3159.289558] [<ffffffff813af295>] cpuidle_idle_call+0xd7/0x168 Aug 21 12:14:45 dark kernel: [ 3159.289560] [<ffffffff81008307>] cpu_idle+0xa5/0xdf Aug 21 12:14:45 dark kernel: [ 3159.289564] [<ffffffff81466d6e>] rest_init+0x72/0x74 Aug 21 12:14:45 dark kernel: [ 3159.289566] [<ffffffff81b66b8b>] start_kernel+0x3ca/0x3d5 Aug 21 12:14:45 dark kernel: [ 3159.289568] [<ffffffff81b662c4>] x86_64_start_reservations+0xaf/0xb3 Aug 21 12:14:45 dark kernel: [ 3159.289570] [<ffffffff81b66140>] ? early_idt_handlers+0x140/0x140 Aug 21 12:14:45 dark kernel: [ 3159.289572] [<ffffffff81b663ca>] x86_64_start_kernel+0x102/0x111 Aug 21 12:14:45 dark kernel: [ 3159.289573] handlers: Aug 21 12:14:45 dark kernel: [ 3159.289587] [<ffffffffa0162bb9>] skge_intr Aug 21 12:14:45 dark kernel: [ 3159.289604] Disabling IRQ #16
Still happens with: Linux dark.omnifarious.org 2.6.40.6-0.fc15.x86_64 #1 SMP Tue Oct 4 00:39:50 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
same bug. any solution?
had a similar problem with 8139too driver(bug 755956), seems related to bug 717211.
Is this still happening with 2.6.43/3.3?
Fedora 15 has reached it's end of life as of June 26, 2012. As a result, we will not be fixing any remaining bugs found in Fedora 15. In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. Thank you for taking the time to file a report. We hope newer versions of Fedora suit your needs.