Created attachment 871303 [details] output of 'dmesg' Description of problem: Additional PCI ethernet card in Sandybridge on Asus M/B runs for a few hours/days, then gets Disabling IRQ 19, Nobody Cared. Version-Release number of selected component (if applicable): kernel-3.13.5-200.fc20.x86_64 (and also earlier versions) How reproducible: Wait a few hours or days until it happens. Actual results: Network card giving up, very slow max speed (approx. 512 kB/s - 1 MB/s) (output in /var/log/messages) Mar 2 15:08:40 b kernel: [ 2859.216892] irq 19: nobody cared (try booting with the "irqpoll" option) Mar 2 21:05:30 b kernel: [24258.376544] irq 19: nobody cared (try booting with the "irqpoll" option) Mar 4 01:35:33 b kernel: [126806.938661] irq 19: nobody cared (try booting with the "irqpoll" option) Mar 5 00:35:18 b kernel: [209548.465023] irq 19: nobody cared (try booting with the "irqpoll" option) Mar 5 14:47:15 b kernel: [260638.885655] irq 19: nobody cared (try booting with the "irqpoll" option) Mar 5 23:57:43 b kernel: [293649.127876] irq 19: nobody cared (try booting with the "irqpoll" option) Mar 6 07:06:43 b kernel: [319376.011053] irq 19: nobody cared (try booting with the "irqpoll" option) (Output by "dmesg") [ 2859.216892] irq 19: nobody cared (try booting with the "irqpoll" option) [ 2859.216897] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.5-200.fc20.x86_64 #1 [ 2859.216898] Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 1104 09/26/2011 [ 2859.216900] ffff880136d11c84 ffff88013fa03e50 ffffffff81686fdc ffff880136d11c00 [ 2859.216903] ffff88013fa03e78 ffffffff810c3402 ffff880136d11c00 0000000000000013 [ 2859.216906] 0000000000000000 ffff88013fa03eb8 ffffffff810c388b 000000000000e4a0 [ 2859.216909] Call Trace: [ 2859.216910] <IRQ> [<ffffffff81686fdc>] dump_stack+0x45/0x56 [ 2859.216920] [<ffffffff810c3402>] __report_bad_irq+0x32/0xd0 [ 2859.216922] [<ffffffff810c388b>] note_interrupt+0x19b/0x1f0 [ 2859.216925] [<ffffffff810c1199>] handle_irq_event_percpu+0xd9/0x1d0 [ 2859.216928] [<ffffffff810c12c7>] handle_irq_event+0x37/0x60 [ 2859.216930] [<ffffffff810c4375>] handle_fasteoi_irq+0x55/0xf0 [ 2859.216934] [<ffffffff8101560f>] handle_irq+0xbf/0x150 [ 2859.216937] [<ffffffff81691bba>] ? atomic_notifier_call_chain+0x1a/0x20 [ 2859.216941] [<ffffffff816981cd>] do_IRQ+0x4d/0xc0 [ 2859.216943] [<ffffffff8168dead>] common_interrupt+0x6d/0x6d [ 2859.216944] <EOI> [<ffffffff815317cf>] ? cpuidle_enter_state+0x4f/0xc0 [ 2859.216950] [<ffffffff815318f9>] cpuidle_idle_call+0xb9/0x1f0 [ 2859.216953] [<ffffffff8101c8fe>] arch_cpu_idle+0xe/0x30 [ 2859.216955] [<ffffffff810c05e5>] cpu_startup_entry+0xc5/0x290 [ 2859.216958] [<ffffffff81678d27>] rest_init+0x77/0x80 [ 2859.216961] [<ffffffff81d22f5c>] start_kernel+0x439/0x444 [ 2859.216963] [<ffffffff81d2292c>] ? repair_env_string+0x5c/0x5c [ 2859.216966] [<ffffffff81d22120>] ? early_idt_handlers+0x120/0x120 [ 2859.216968] [<ffffffff81d225de>] x86_64_start_reservations+0x2a/0x2c [ 2859.216970] [<ffffffff81d2271e>] x86_64_start_kernel+0x13e/0x14d [ 2859.216971] handlers: [ 2859.216979] [<ffffffffa02d8040>] rtl8169_interrupt [r8169] [ 2859.216980] Disabling IRQ #19 Expected results: Network card not giving up Additional info: As soon as the IRQ gets disabled, the first two lines of /proc/irq/19/spurious read: count 0 unhandled 0 This situation can be repaired on the live system with these commands: # rmmod r8169 # modprobe r8169
Created attachment 871305 [details] /proc/interrupts
Created attachment 871306 [details] output of 'lspci'
Created attachment 871307 [details] output of 'lspci -v'
Created attachment 871308 [details] output of 'lspci -vv'
This bug can also be found on https://bugzilla.kernel.org/show_bug.cgi?id=38632 (WONT_FIX). I have, sort of, 'fixed' the problem by creating this entry in root's crontab: */15 * * * * grep '^count 0$' /proc/irq/19/spurious && /sbin/rmmod r8169 && /sbin/modprobe r8169
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.