Re: Interrupt storm detection

> On Fri, 11 Jun 2004, Ian FREISLICH wrote:
> 
> > I have a problem printing.  The data rate through my parallel port
> > to my printer makes the kernel think that lpt0 is storming at between
> > 40k-49k irqs per second.  Is there a way to tell the kernel to
> > ignore certain interrupt sources or to raise the per-second throttle
> > value?  I've only found hw.intr_storm_threshold which I assume is
> > the number of interrupts from a source before an interrupt arives
> > from another source.  I've set this to 2000 to make the printing
> > work, but now I'm not sure if this will protect from a real interrupt
> > storm.
> 
> The throttle value hw.intr_storm_threshold is actually the limit on the
> number of interrupts from a source that arrive as fast as they can be
> handled.  If interrupts arrive faster than they can be handled, then
> there really is a storm.

Ok, so the counter increments if there is an interrupt waiting to
be serviced when the routine returns?

> The DELAY(1) that I added to interrupt handling may have broken things
> for devices that interrupt too much like lpt0 :-(.  DELAY(1) takes
> quite a bit longer than 1 usec (more like 5 usec).  It looks like lpt0
> takes 15-20 usec per interrupt and when 5 usec is added to this the
> machine is transiently overloaded and doesn nothing except handle lpt0
> interrupts until it complete a write, taking 20-25 usec each.  A
> slightly slower machine might be overloaded even without the DELAY(1).

Does a PII-266 constitute a slightly slower machine?

> by the DELAY(1) should be recovered from eventually.  For lpt0, initial
> misdetection would cause lpt0 interrupts to be throttled to about 1/HZ
> hz.  It may take a long while to print files at this rate, but eventually
> you will run out of things to print (or give up :-).  Then the throttle

Yeah, my wife gave up and phoned me to fix.

> storm and the problem will recur.  I think it is possible for output
> to lpt0 to transiently overload the machine -- it just takes a printer
> has more than interrupt_storm_threshold bytes of buffering and can ack
> each character that it receives as fast as the interrupt handler can
> deliver them.  (Old driver timing bugs are also relevant here.  The

Yes, it's a laser printer with 36Mb of memory and probably a faster
CPU than server to which it's connected.

> lpt interrupt handler has few clues about interrupt timing.  It waits
> (for possibly too long) on entry but doesn't wait or even check for
> another interrupt to arrive after it sends a character to the printer.
> Thus getting another interrupt as soon as it returns is the usual case
> if the printer hardware does the right things.)

How easy would this be to fix?  It's possible that the routing might
not return for quite a long time if it checks for an interrupt
before it returns, or is this not a bad thing because because it's
an interrupt thread and getting stuck in it won't hold up the whole
system?

Ian

--
Ian Freislich