Joerg Sonnenberger <jo...@britannica.bec.de> writes: > If it still generates interrupts, there is not much we can do. I do not > believe turning off interrupts on the PIC is in any way appropiate.
All right, but before we drop this, could you help me understand your experimental patch that I'm running? It looks to me as if you're never enabling the uhci interrupts, instead scheduling the first of a series of callouts, with the intention that each such callout will end up re-scheduling a new one. (There is a code path in uhci_intr1() that would break this chain, but I'm assuming that's either never hit, or the fact that I'm getting spurious interrupts is keeping things running anyway: it's the if (!ack) return (0); /* nothing to acknowledge */ near the end of the function, which I would have expected to have its own call to callout_schedule(), like the other ones.) So, the uhci_intr1() function should end up being called HZ times per second, plus once for each spurious interrupt, which will hit this: if (status == 0) { /* The interrupt was not for us. */ callout_schedule(&sc->sc_simulated_interrupt, 1); return (0); } and thus schedule another call if one isn't already pending. This one I would actually think wasn't needed, and I'm tempted to move the call to the other return path, quoted above. Have I got this right so far? If I do, I'm also thinking that the same idea could easily be applied to ehci, right? That's now my largest source of unwanted interrupts at the physical level, so I figure it's worth it to do the same thing there. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"