From owner-freebsd-current  Thu Sep 24 15:06:52 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id PAA25599
          for freebsd-current-outgoing; Thu, 24 Sep 1998 15:06:52 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25568;
          Thu, 24 Sep 1998 15:06:39 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id IAA31935;
	Fri, 25 Sep 1998 08:06:33 +1000
Date: Fri, 25 Sep 1998 08:06:33 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199809242206.IAA31935@godzilla.zeta.org.au>
To: gibbs@plutotech.com, mike@smith.net.au
Subject: Re: options DPT_LOST_IRQ
Cc: bde@FreeBSD.ORG, current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>If it stops asserting the interrupt, we should get a stray interrupt
>reported when we go to clear the pending mask.  Is this what is happening?

No to the "should" statement.  Stray interrupts are only reported when an
interrupt goes away during the middle of an interrupt acknowledge cycle.
This should be extremely rare.  However, returning from an interrupt
handler a little too soon (only for broken/slow hardware?) may cause
a race between the device deasserting the interrupt and clearing the
interupt mask (the mask in the CPU or the PIC; it's on a different
device so their is no synchronization except for the CPU's guarantee to
serialize i/o).

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message