From owner-freebsd-current Thu Sep 24 16:52:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA14036 for freebsd-current-outgoing; Thu, 24 Sep 1998 16:52:46 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from nomis.simon-shapiro.org (nomis.simon-shapiro.org [209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA14003 for ; Thu, 24 Sep 1998 16:52:27 -0700 (PDT) (envelope-from shimon@simon-shapiro.org) Received: (qmail 6270 invoked by uid 1000); 25 Sep 1998 00:56:27 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199809242301.JAA03399@godzilla.zeta.org.au> Date: Thu, 24 Sep 1998 20:56:27 -0400 (EDT) X-Face: (&r=uR0&yvh>h^ZL4"-TH61PD}/|Y'~58Z# Gz&BK'&uLAf:2wLb~L7YcWfau{;N(#LR2)\i.l8'ZqVhv~$rNx$]Om6Sv36S'\~5m/U'"i/L)&t$R0&?,)tm0l5xZ!\hZU^yMyCdt!KTcQ376cCkQ^Q_n.GH;Dd-q+ O51^+.K-1Kq?WsP9;cw-Ki+b.iY-5@3!YB5{I$h;E][Xlg*sPO61^5=:5k)JdGet,M|$"lq!1!j_>? $0Yc? Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Bruce Evans Subject: Re: options DPT_LOST_IRQ Cc: current@FreeBSD.ORG, eivind@yes.no, mcdougall@ameritech.net, gibbs@plutotech.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans, On 24-Sep-98 you 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. You may be right, but the only two operating systems I am aware of this problem, are Linux and FreeBSD. Both are using fast interrupts, the freeBSD old driver was drastically different from the Linux one (although Mike and me know each other very well). The CAM driver looks radically different from what I wrote (although some of the code looks familiar :-). All three implementations share almost nothing in common, except the use of fast interrupts. I do not profess to be any expert on FreeBSD interupts, but am still at a loss. BTW, there is at least one gentleman who knowns rather well the code, and I am sure observes this thred with amusement, but I'd rather have him be busy with what he does now, then be dragged into this... Remember, this is pre-release time, everyone is edgy, be cool. Things will work shortly. Sincerely Yours, Shimon@Simon-Shapiro.ORG 770.265.7340 Simon Shapiro Unwritten code has no bugs and executes at twice the speed of mouth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message