On Sun, 2 Feb 2014, Josh Bendavid wrote: > Alan Stern <stern@...> writes: > > > > > On Thu, 23 Jan 2014, Josh Bendavid wrote: > > > > > Hi Alan, > > > Is it understood why/how this always happens when the interrupt counter for > > > this device reaches exactly 200001? I would have assumed that this was a > > > software counter in the kernel, in which case I don't see how this could > > > correlate to a hardware bug. > > > > The kernel keeps track of unhandled interrupts, and you get that > > "nobody cared" error when the number exceeds 99900 in a 0.1-second > > period. But the test for this condition occurs only at intervals of > > 100000 interrupts. > > > > In any case, you can try applying the patch below. It should print out > > some relevant information for the 100 interrupts before and after > > number 200001. In particular, we should be able to tell whether or not > > each interrupt was handled by ohci-hcd. > > > > Alan Stern > > > > Index: usb-3.13/drivers/usb/host/ohci-hcd.c > > =================================================================== > > --- usb-3.13.orig/drivers/usb/host/ohci-hcd.c > > +++ usb-3.13/drivers/usb/host/ohci-hcd.c > > <at> <at> -784,6 +784,7 <at> <at> static irqreturn_t ohci_irq > (struct usb_ > > struct ohci_hcd *ohci = hcd_to_ohci (hcd); > > struct ohci_regs __iomem *regs = ohci->regs; > > int ints; > > + static int alancnt; > > > > /* Read interrupt status (and flush pending writes). We ignore the > > * optimization of checking the LSB of hcca->done_head; it doesn't > > <at> <at> -791,6 +792,11 <at> <at> static irqreturn_t ohci_irq > (struct usb_ > > */ > > ints = ohci_readl(ohci, ®s->intrstatus); > > > > + if (++alancnt >= 199900 && alancnt < 200100) > > + ohci_info(ohci, "IRQ %d status %x enable %x\n", > > + alancnt, ints, > > + ohci_readl(ohci, ®s->intrenable)); > > + > > /* Check for an all 1's result which is a typical consequence > > * of dead, unclocked, or unplugged (CardBus...) devices > > */ > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > > the body of a message to majordomo@... > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > Hi Alan, > (sorry for the delay) > With this last patch (but NOT including the earlier workaround patch), I get > this additional output periodically in the dmseg > > [ 6998.342658] mceusb 4-3:1.0: rx data: 9e 52 82 24 86 23 87 0e 87 23 87 7f > 7f 7f 7f 7f 7f 6e 87 23 87 0e 86 0f 86 0f 87 0e 86 0f 86 (length=31) > [ 6998.342662] mceusb 4-3:1.0: Raw IR data, 30 pulse/space samples > [ 6998.342665] mceusb 4-3:1.0: Storing space with duration 4100000 > [ 6998.342668] mceusb 4-3:1.0: Storing pulse with duration 100000 > [ 6998.342671] mceusb 4-3:1.0: Storing space with duration 1800000 > [ 6998.342674] mceusb 4-3:1.0: Storing pulse with duration 300000 > [ 6998.342677] mceusb 4-3:1.0: Storing space with duration 1750000 > [ 6998.342680] mceusb 4-3:1.0: Storing pulse with duration 350000 > [ 6998.342682] mceusb 4-3:1.0: Storing space with duration 700000 > [ 6998.342685] mceusb 4-3:1.0: Storing pulse with duration 350000 > [ 6998.342688] mceusb 4-3:1.0: Storing space with duration 1750000 > [ 6998.342691] mceusb 4-3:1.0: Storing pulse with duration 350000 > [ 6998.342694] mceusb 4-3:1.0: Storing space with duration 6350000 > [ 6998.342697] mceusb 4-3:1.0: Storing space with duration 6350000 > [ 6998.342699] mceusb 4-3:1.0: Storing space with duration 6350000 > [ 6998.342702] mceusb 4-3:1.0: Storing space with duration 6350000 > [ 6998.342705] mceusb 4-3:1.0: Storing space with duration 6350000 > [ 6998.342708] mceusb 4-3:1.0: Storing space with duration 6350000 > [ 6998.342711] mceusb 4-3:1.0: Storing space with duration 5500000 > [ 6998.342713] mceusb 4-3:1.0: Storing pulse with duration 350000 > [ 6998.342716] mceusb 4-3:1.0: Storing space with duration 1750000 > [ 6998.342719] mceusb 4-3:1.0: Storing pulse with duration 350000 > [ 6998.342722] mceusb 4-3:1.0: Storing space with duration 700000 > [ 6998.342725] mceusb 4-3:1.0: Storing pulse with duration 300000 > [ 6998.342727] mceusb 4-3:1.0: Storing space with duration 750000 > [ 6998.342730] mceusb 4-3:1.0: Storing pulse with duration 300000 > [ 6998.342733] mceusb 4-3:1.0: Storing space with duration 750000 > [ 6998.342736] mceusb 4-3:1.0: Storing pulse with duration 350000 > [ 6998.342739] mceusb 4-3:1.0: Storing space with duration 700000 > [ 6998.342742] mceusb 4-3:1.0: Storing pulse with duration 300000 > [ 6998.342744] mceusb 4-3:1.0: Storing space with duration 750000 > [ 6998.342747] mceusb 4-3:1.0: Storing pulse with duration 300000 > [ 6998.342750] mceusb 4-3:1.0: processed IR data, calling ir_raw_event_handle > [ 6998.348752] systemd-journald[195]: Vacuuming done, freed 131072 bytes These messages have no connection with the patch. What you should see, just once not long after you boot up or start using the device, is about 200 messages mentioning IRQ counts and register values (from the ohci_info call in the patch). Did the "nobody cared" error occur while you were testing the patch? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
