On Tue, Apr 23, 2024 at 10:04:17AM -0700, Guenter Roeck wrote: > Hi, > > when testing usb-ohci What is usb-ohci? Do you mean ohci-hcd? > with qemu's pci-ohci emulation, I keep getting > random usb interface timeouts. Sometimes the usb_hub_wq times out. ... > Sometimes there is an i/o scheduling timeout such as ... > This is not a new problem; I have seen it forever. Recently I spent some > time trying to understand the problem and found that the linux driver does > not always handle all ohci interupts. Please be more specific: _Which_ interrupts aren't being handled? That is, which flags remain set in the intrstatus register when the handler returns? > Since the interrupt is shared and > thus level triggered, that means that interrupts are still pending when > ohci_irq() exits. The interrupt core in Linux does not re-enter the > interrupt handler, presumably because it is marked as shared interrupt > and returns that the interrupt has been handled. Isn't that behavior mistaken? A level-triggered IRQ that remains set when it is re-enabled (when the various shared handlers return) should cause another interrupt to occur right away. Edged-triggered interrupts would be a different story, of course. > I found two possible fixes for the problem. One essentially mirrors the > code from ehci_irq(), the other adds a (bad) kludge into qemu. Both "fix" > or work around the problem. > > Question is: What is actually wrong ? Something in the generic interrupt > handling code in Linux, something in the Linux usb-ohci driver, or > something in qemu ? Any idea how a proper fix might look like ? To answer these questions we need more information. Alan Stern
