From owner-freebsd-current Thu Sep 24 16:02:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA05706 for freebsd-current-outgoing; Thu, 24 Sep 1998 16:02:15 -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 QAA05600 for ; Thu, 24 Sep 1998 16:01:52 -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 JAA03399; Fri, 25 Sep 1998 09:01:33 +1000 Date: Fri, 25 Sep 1998 09:01:33 +1000 From: Bruce Evans Message-Id: <199809242301.JAA03399@godzilla.zeta.org.au> To: gibbs@plutotech.com, shimon@simon-shapiro.org Subject: Re: options DPT_LOST_IRQ Cc: current@FreeBSD.ORG, eivind@yes.no, mcdougall@ameritech.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message