Re: Interrupt storm mitigation needed

[Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>]

Joerg Sonnenberger <joerg%britannica.bec.de@localhost> 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"