Skip site navigation (1)Skip section navigation (2)
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>