From owner-freebsd-current Thu Sep 24 14:34:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20196 for freebsd-current-outgoing; Thu, 24 Sep 1998 14:34:01 -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 OAA20165; Thu, 24 Sep 1998 14:33:47 -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 HAA29879; Fri, 25 Sep 1998 07:33:36 +1000 Date: Fri, 25 Sep 1998 07:33:36 +1000 From: Bruce Evans Message-Id: <199809242133.HAA29879@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 >> >This option is necessary due to interrupts being eaten by the serial >> >driver 'fast interrupt' code (which in some cases blocks interrupts >> >longer than the DPT assert them). It's surprising that hardware more expensive than a $0.25 printer interface does that. Some OS's sometimes block interrupts for several msec. FreeBSD only sometimes blocks "slow" interrupts for several msec. If the DPT interrupt is shared with another (slow) interrupt, then it will be blocked when the handler for the other interrupt runs, anyway. >For all their efficiency benefits, I think fast interrupts are Evil. What efficiency benefits are those? The main point of fast interrupts is to preempt braindamaged slow interrupt handlers that sometimes block interrupts for several msec (or even 100 usec), so that we don't have to rewrite all the braindamaged handlers or actively schedule them. (There are some minor efficiency benefits, mostly from not having to fiddle with the PIC.) Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message