Date: Fri, 5 Apr 1996 10:43:36 -0800 (PST) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, current@freebsd.org, jgreco@brasil.moneng.mei.com, nate@sri.MT.net, root@deadline.snafu.de Subject: Re: tty-level buffer overflows - what to do? Message-ID: <199604051843.KAA09197@GndRsh.aac.dev.com> In-Reply-To: <199604051809.EAA17652@godzilla.zeta.org.au> from Bruce Evans at "Apr 6, 96 04:09:20 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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.
That event is way way after the DEFAULT IR7 occurs...
- the ESL is reset (negative logic) when the IRx signal goes from low to
high. [Needed to add this since you failed to mention how it gets set
in the first place]
> - 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
^ESL oopsss...
> >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.
Like I said bruce if there ain't no INTA this whole discussion is
pointless! FreeBSD has DIED if INTA does not occur at some time.
I think we need to end this, it is going no place, we both understand
how the 8259A works, hell, we both probably have detailed logic diagrams
of the damn thing.
Simple fact of the mater is if someone asserts an IRx signal, then removes
that signal before an INTA cycle completes with 8259 will signal this as
an IRQ7 interrupt. Don't tell me again that INTA is not going to occur,
because if it is not going to occur FreeBSD has stopped running....
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604051843.KAA09197>