Date: Thu, 20 Nov 2003 07:44:53 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: David Schultz <das@freebsd.org> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: cvs commit: src/sys/i386/isa atpic.c Message-ID: <20031120073347.L9022@gamplex.bde.org> In-Reply-To: <20031119162804.GA66857@VARK.homeunix.com> References: <200311191540.hAJFeOGx058737@repoman.freebsd.org> <20031119162804.GA66857@VARK.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031120073347.L9022>