From owner-freebsd-current Fri Apr 5 10:11:26 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA29949 for current-outgoing; Fri, 5 Apr 1996 10:11:26 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA29944 for ; Fri, 5 Apr 1996 10:11:23 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id EAA17652; Sat, 6 Apr 1996 04:09:20 +1000 Date: Sat, 6 Apr 1996 04:09:20 +1000 From: Bruce Evans Message-Id: <199604051809.EAA17652@godzilla.zeta.org.au> To: bde@zeta.org.au, rgrimes@GndRsh.aac.dev.com Subject: Re: tty-level buffer overflows - what to do? Cc: current@freebsd.org, jgreco@brasil.moneng.mei.com, nate@sri.MT.net, root@deadline.snafu.de Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Of course I checked before posting, and it has to work like I said or >> there would be a stray interrupt every time a debugger disables clock >> interrupts for more than one clock tick (since interrupts are edge >> sensitive the edge trigger latch would hold any acknowledged interrupt >> until it is EOI'ed). >The ISR latch holds an interrupt until it is EOI'ed. There are three >latches in there. The ``edge sense latch'', the ``request latch (aka IRR)'', >and the ``in-service latch (ISR)''. >... More completely: - the ISR latch is set when the interrupt is acknowledged and cleared when the interrupt is EOI'ed. - the `edge sense latch' (ESL) is set (negative logic) when the interrupt is acknowledged (after the ISR is set) and cleared when the interrupt goes away AND the ISR is clear. - the IRR latch is quite different. "Be sure top notice that the request latch is a transparent D type latch". If the ESL is clear, then the IRR follows the IRQ signal. If the ESL is set, then the IRR is in braindamaged mode: it is held low by ESL. >> >In both the edge and level triggered modes the IR inputs >> >must remain high until after the falling edge of the first >> ^^^^^ >> >INTA. If the IR input goes low before this time a DEFAULT >> ^^^^ > ^^^^^^^^^^^^^^^^^^^^ >> >IR7 will occur when the CPU acknowledges the interrupt. >> >> When there's no INTA, there's no first INTA, so it doesn't matter >> what the IR inputs do. >Well, if there is no INTA I would say FreeBSD is pretty dead in the >water. Sooner or later you going to run that INTA cycle that is >going to cause the stray int 7. Remeber, the IRR is still set even >though IRx has gone away. [It is this later fact that causes the >logic in the resolver to default to a 7]. No, the IRR isn't set. Only the ESL remembers the IRQ state, and it isn't active because there's no INTA. Bruce