From owner-freebsd-current@FreeBSD.ORG Fri Jun 11 14:02:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 096A316A4CE for ; Fri, 11 Jun 2004 14:02:32 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 892CD43D2F for ; Fri, 11 Jun 2004 14:02:31 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1BYmbX-000Ixx-00; Fri, 11 Jun 2004 16:01:59 +0200 To: Bruce Evans From: Ian FREISLICH In-Reply-To: Message from Bruce Evans <20040611213707.B13626@gamplex.bde.org> Date: Fri, 11 Jun 2004 16:01:59 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: current@freebsd.org Subject: Re: Interrupt storm detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2004 14:02:32 -0000 > 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