From owner-freebsd-smp  Sat Nov  2 22:44:12 1996
Return-Path: owner-smp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id WAA00284
          for smp-outgoing; Sat, 2 Nov 1996 22:44:12 -0800 (PST)
Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA00273;
          Sat, 2 Nov 1996 22:44:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id XAA25052; Sat, 2 Nov 1996 23:43:56 -0700
Message-Id: <199611030643.XAA25052@clem.systemsix.com>
X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol
X-Mailer: exmh version 1.6.5 12/11/95
From: Steve Passe <smp@csn.net>
To: dg@Root.COM
cc: hackers@freefall.freebsd.org, smp@freefall.freebsd.org
Subject: Re: ed0 timeouts 
In-reply-to: Your message of "Fri, 25 Oct 1996 14:10:45 PDT."
             <199610252110.OAA08906@root.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 02 Nov 1996 23:43:56 -0700
Sender: owner-smp@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Hi,

>>I currently am writing code for the FreeBSD SMP kernel that will allow
>> ...
>>I am occasionally loosing the INTs expected to be generated by ed_xmit().
>>The ed_watchdog() routine usually recovers gracefully (network actually 
locked
>>twice since running this code: approx 2/3 weeks).  Could someone explain
>>why the ed0 cards might loose this INT?  Any clues/insight appreciated!

> ...  It sounds much more
>like a problem acking ISA interrupts, or perhaps a bug in the handling of
>the interrupt masks. ...

Question:

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?

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.

What about a scenerio where an async receive packet occured while servicing
a TXMIT INT:  The received packet causes a bus level edge INT to be asserted,
which is lost, as it is masked by edintr() (for the XMIT INT).  Now edintr()
finishes, unmasking the INT, and eventually another XMIT INT occurs.  BUT
the board doesn't assert another edge because it already has the RCV INT
"active", which was lost, but the hardware assumes it is pending.
Does this sound feasable?

--
Steve Passe	| powered by
smp@csn.net	|            FreeBSD

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE
04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX
WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR
tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+
=ds99
-----END PGP PUBLIC KEY BLOCK-----