From owner-freebsd-current@FreeBSD.ORG Fri Jun 11 16:45:37 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 CC9BA16A4CE for ; Fri, 11 Jun 2004 16:45:37 +0000 (GMT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E9C543D55 for ; Fri, 11 Jun 2004 16:45:37 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd11.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1BYp9q-0003J7-05; Fri, 11 Jun 2004 18:45:34 +0200 Received: from Andro-Beta.Leidinger.net (rCUmvGZvZe9s85kX4vH98EewaDNGPna+txIwhicoqemWtBlAxOOPsj@[217.229.210.30]) by fmrl11.sul.t-online.com with esmtp id 1BYp9c-1VieSe0; Fri, 11 Jun 2004 18:45:20 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i5BGjZSp064408; Fri, 11 Jun 2004 18:45:35 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Fri, 11 Jun 2004 18:47:06 +0200 From: Alexander Leidinger To: Ian FREISLICH Message-Id: <20040611184706.11a8de5b@Magellan.Leidinger.net> In-Reply-To: References: <20040611213707.B13626@gamplex.bde.org> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: rCUmvGZvZe9s85kX4vH98EewaDNGPna+txIwhicoqemWtBlAxOOPsj@t-dialin.net 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 16:45:37 -0000 On Fri, 11 Jun 2004 16:01:59 +0200 Ian FREISLICH wrote: > > 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? I've just seen this on my 1 GHz Athlon. > > 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. In my case it's a DeskJet 895 Cxi wich gets feeded by ghostscript (btw. is someone able to print via usb? It doesn't work here anymore :-( ). > > 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? I had no problems working on the system while the printer sloooooowly printed 2 pages. Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7