Date: Fri, 11 Jun 2004 16:01:59 +0200 From: Ian FREISLICH <if@hetzner.co.za> To: Bruce Evans <bde@zeta.org.au> Cc: current@freebsd.org Subject: Re: Interrupt storm detection Message-ID: <E1BYmbX-000Ixx-00@hetzner.co.za> In-Reply-To: Message from Bruce Evans <bde@zeta.org.au> <20040611213707.B13626@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1BYmbX-000Ixx-00>