From owner-freebsd-hackers Mon Dec 30 15:15:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA27662 for hackers-outgoing; Mon, 30 Dec 1996 15:15:54 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA27655 for ; Mon, 30 Dec 1996 15:15:48 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id KAA13090; Tue, 31 Dec 1996 10:12:14 +1100 Date: Tue, 31 Dec 1996 10:12:14 +1100 From: Bruce Evans Message-Id: <199612302312.KAA13090@godzilla.zeta.org.au> To: hackers@freebsd.org, hmmm@alaska.net Subject: Re: Ints Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Q: is there danger in servicing a lower priority pending interrupt while >servicing the highest priority INT in the same ISR ? Only if there are bugs. >IE - are any interrupt functions/bits LATCHED - that may need to be >cleaned up? They are not latched by ISA hardware. They are latched by FreeBSD software, except for some serial interrupts. >for example - i have both COM ports tied to the same ISR - is there any >danger in reading RxBuf1 (lower priority) while SERVICING an RxBuf2 INT? There is extreme danger of this not working at all, for other reasons - ISA hardware doesn't support sharing interrupts (at the same time). >or - satisfying a TxBuf INT (lower priority) while taking care of RxBuf >INT? > >OR - does eliminating any INTerrupt condition KILL all things related to >that INTerrupt? The events that cause the interrupts can be handled in any order for xx(x)50 UARTs, except for bugs of course. 8250s have bugs involving losing modem control (?) interrupts while other interrupts are being handled. Bruce