From owner-cvs-all@FreeBSD.ORG Wed Nov 19 12:45:03 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A900616A4CE; Wed, 19 Nov 2003 12:45:03 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5285A43FD7; Wed, 19 Nov 2003 12:45:01 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id HAA18053; Thu, 20 Nov 2003 07:44:53 +1100 Date: Thu, 20 Nov 2003 07:44:53 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Schultz In-Reply-To: <20031119162804.GA66857@VARK.homeunix.com> Message-ID: <20031120073347.L9022@gamplex.bde.org> References: <200311191540.hAJFeOGx058737@repoman.freebsd.org> <20031119162804.GA66857@VARK.homeunix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: John Baldwin Subject: Re: cvs commit: src/sys/i386/isa atpic.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2003 20:45:03 -0000 On Wed, 19 Nov 2003, David Schultz wrote: > On Wed, Nov 19, 2003, John Baldwin wrote: > > jhb 2003/11/19 07:40:23 PST > > > > FreeBSD src repository > > > > Modified files: > > sys/i386/isa atpic.c > > Log: > > Add a special check for a stray IRQ 7 or IRQ 15 to see if it is actually > > a spurious interrupt from one of the 8259As. If so, don't log it as a > > stray IRQ, but just silently ignore it. Sigh, more instructions in what used to be the fast path for interrupt handlers. (E.g., sio interrupts now take more instructions outside of the driver than it used to take to handle whole interrupts. Unfortunately for my argument, the i/o instructions in the driver can take hundreds or thousands as long as many of the instructions in the bloated path, so the bloat mainly affects old machines.) > Nice. I've been waiting for years for someone who understood the > full flakiness of the i8259 to fix the spurious messages. The spurious messages are a feature. They give you a clue that an interrupt might have been lost. Whether the loss is important is device and device-driver dependent (if loss is serious and happens then the driver needs to poll occasionally). The spurious message used to be broken by attaching the interrupt to a device driver that ignores it. This is often misadvised as a fix. The correct fix probably involves always checking for spurious interrupts on IRQ7 and IRQ15, and when one is detected, broadcasting it to all interrupt handlers in case it was for their device. All interrupt handlers should be prepared for interrupts that aren't for them, and all interrupt handlers for interrupts that may be shared must be prepared for this. Alternatively, just assume that interrupts are lost occasionally and broadcast a fake interrupt occasionally. Bruce