Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Sep 1998 23:38:59 -0400
From:      john hood <cgull@owl.org>
To:        Bruce Evans <bde@zeta.org.au>, gibbs@plutotech.com, shimon@simon-shapiro.org
Cc:        current@FreeBSD.ORG, eivind@yes.no, mcdougall@ameritech.net, sos@FreeBSD.ORG
Subject:   Re: options DPT_LOST_IRQ
Message-ID:  <19980924233859.21276@owl.org>
In-Reply-To: <199809242301.JAA03399@godzilla.zeta.org.au>; from Bruce Evans on Fri, Sep 25, 1998 at 09:01:33AM %2B1000
References:  <199809242301.JAA03399@godzilla.zeta.org.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 25, 1998 at 09:01:33AM +1000, Bruce Evans wrote:
> >b. In the case of a cache hit, the DPT will complete operations and
> >   generate interrupts less than a microsecond apart. The (now removed,
> >   soon to be added again) measure_performance option demonstrates this
> >   clearly.  Such bursts can have up to 64 interrupts per burst.  The
> >   FreeBSD interrupt code has known holes in it, that will cause such
> >   closely spaced interrupts to be lost.  This can also cause the system to
> >   hang.
> 
> I don't know of any holes.  If a device raises and lowers its irq in less
> than a microsecond, then it comes close to violating best-case PIC timing.
> In any case, ix86's can not process an interrupt in less than about 5
> i/o times (perhaps 2.5-6 usec) in the best case.  If a device raises
> and lowers its 64 times in < 64 usec, then at best the handler would see
> about 64/2.5 separate interrupts.  This is with a generous allocation of
> 1 i/o time for device-specific interrupt handling.

This isn't true for systems/software using APICs, no?

A quick perusal of the code seems to show that they use memory-mapped
I/O, less of it than a PIC, and IIRC, it's not across an
ISA-speed bus.

  --jh

-- 
Mr. Belliveau said, "the difference was the wise,       John Hood,     cgull
intelligent look on the face of the cow."  He was      	                   @
*so* right.  --Ofer Inbar                                            owl.org

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980924233859.21276>