From owner-freebsd-smp  Sun Nov  3 00:32:15 1996
Return-Path: owner-smp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id AAA06310
          for smp-outgoing; Sun, 3 Nov 1996 00:32:15 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA06301;
          Sun, 3 Nov 1996 00:32:08 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id TAA24597; Sun, 3 Nov 1996 19:29:10 +1100
Date: Sun, 3 Nov 1996 19:29:10 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199611030829.TAA24597@godzilla.zeta.org.au>
To: dg@Root.COM, smp@csn.net
Subject: Re: ed0 timeouts
Cc: hackers@freefall.freebsd.org, smp@freefall.freebsd.org
Sender: owner-smp@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>Is it possible for a new INT to be asserted by the if_ed driver WHILE
>it is currently being serviced by the edintr() routine?

Probably.  It is certainly possibly for other ISA devices.  The IRQ
tends to go low when you read the status register and then there can
be another edge when another event occurs.

>What I have discovered is that unlike the 8259, the IO APIC will ignore
>(ie NOT delivered or held pending) an edge level INT if it currently is
>masked.  The routine in vector.s masks the INT, calls edintr(), then after
>edintr() returns it unmasks the INT.  If another INT fired as a result
>of ed_start() being called in edintr() BEFORE the INT was unmasked it
>would be LOST.

It seems to be more braindamaged than an 8259 :-(.  (The main 8259
braindamage is that you can't see the state of the IRQ lines directly
except while interrupts are masked and not in service.)

Bruce