Interrupt storm detection
if at hetzner.co.za
Fri Jun 11 14:02:32 GMT 2004
> 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
More information about the freebsd-current