Hi,
this bug hits my system now a long time. I had found e.g. this
speedy kernel: [ 9575.033019] irq 16: nobody cared (try booting with the "irqpoll" option)
speedy kernel: [ 9575.033022] Pid: 0, comm: swapper/0 Not tainted 3.7.10-1.1-desktop #1
speedy kernel: [ 9575.033023] Call Trace:
speedy kernel: [ 9575.033031] [<ffffffff81004818>] dump_trace+0x88/0x300
speedy kernel: [ 9575.033035] [<ffffffff8158b033>] dump_stack+0x69/0x6f
speedy kernel: [ 9575.033038] [<ffffffff810d6c56>] __report_bad_irq+0x36/0xe0
speedy kernel: [ 9575.033041] [<ffffffff810d7158>] note_interrupt+0x1e8/0x240
speedy kernel: [ 9575.033045] [<ffffffff810d4772>] handle_irq_event_percpu+0xc2/0x250
speedy kernel: [ 9575.033047] [<ffffffff810d4947>] handle_irq_event+0x47/0x70
speedy kernel: [ 9575.033049] [<ffffffff810d7c50>] handle_fasteoi_irq+0x60/0x100
speedy kernel: [ 9575.033051] [<ffffffff810046c8>] handle_irq+0x18/0x30
speedy kernel: [ 9575.033053] [<ffffffff810043a2>] do_IRQ+0x52/0xd0
speedy kernel: [ 9575.033056] [<ffffffff8159806d>] common_interrupt+0x6d/0x6d
speedy kernel: [ 9575.033061] [<ffffffff8132018c>] intel_idle+0xec/0x160
speedy kernel: [ 9575.033064] [<ffffffff81452e0d>] cpuidle_idle_call+0x9d/0x330
speedy kernel: [ 9575.033067] [<ffffffff8100be0a>] cpu_idle+0x6a/0xe0
speedy kernel: [ 9575.033071] [<ffffffff81ac8bc8>] start_kernel+0x3b8/0x3c3
speedy kernel: [ 9575.033073] [<ffffffff81ac8436>] x86_64_start_kernel+0x105/0x114
speedy kernel: [ 9575.033075] handlers:
speedy kernel: [ 9575.033077] [<ffffffff813f2220>] usb_hcd_irq
speedy kernel: [ 9575.033080] [<ffffffffa0282940>] rtl8139_interrupt [8139too]
speedy kernel: [ 9575.033080] Disabling IRQ #16
IRQ 16 is used by ehci_hcd:usb1 and eth1. Adding the "irqpoll" option to the kernels
command line had not helped. Therefore I had debugged this problem by adding a printk()
debug line in the ehci_irq() function of drivers/usb/host/ehci-hcd.c. This had shown
out that my USB controller causes STS_RECL (reclamation readonly status bit) in the
IRQ status.
After a while this had lead to the message in the subject with the side effect that
networking becomes slow.
From the debugging code I've evolved the attached patch. It is not perfect as it
returns IRQ_NONE for the first time the STS_RECL status bit is found but it does
its job.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
---
drivers/usb/host/ehci-hcd.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- drivers/usb/host/ehci-hcd.c
+++ drivers/usb/host/ehci-hcd.c 2014-05-13 12:03:10.098235729 +0000
@@ -686,6 +686,7 @@ static irqreturn_t ehci_irq (struct usb_
u32 status, masked_status, pcd_status = 0, cmd;
int bh;
unsigned long flags;
+ static u32 spurious_recl;
/*
* For threadirqs option we use spin_lock_irqsave() variant to prevent
@@ -707,11 +708,19 @@ static irqreturn_t ehci_irq (struct usb_
* We don't use STS_FLR, but some controllers don't like it to
* remain on, so mask it out along with the other status bits.
*/
- masked_status = status & (INTR_MASK | STS_FLR);
+ masked_status = status & (INTR_MASK | STS_FLR | spurious_recl);
/* Shared IRQ? */
if (!masked_status || unlikely(ehci->rh_state == EHCI_RH_HALTED)) {
spin_unlock_irqrestore(&ehci->lock, flags);
+ if (unlikely(masked_status & STS_RECL)) {
+ /*
+ * Avoid repeated schedule status reclamation done
+ * by some controllers.
+ */
+ printk(KERN_WARNING "ehci_irq status: %#8.8x", status);
+ spurious_recl |= STS_RECL;
+ }
return IRQ_NONE;
}
Attachment:
pgp7BFJMPZgYW.pgp
Description: PGP signature
