Date: Fri, 5 Apr 1996 09:15:27 -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: <199604051715.JAA08863@GndRsh.aac.dev.com> In-Reply-To: <199604051551.BAA12866@godzilla.zeta.org.au> from Bruce Evans at "Apr 6, 96 01:51:01 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> >> >This is not quite correct, IRQ 7 is signal when someone asserts an IRQ singal
> >> >then removes that signal _before_ the CPU runs the interrupt acknowledge
> >> >cycle to the 8259 PIC.
> >>
> >> This is not quite correct :-). IRQ7 is signaled when an IRQ signal is
> >> removed _during_ the interrupt acknowledge cycle for that IRQ. It isn't
> >> signaled if the cycle never begins.
>
> >You had better go read the data book again, and look at the schematics to
> >the real 8259A if you have access to them.
>
> 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)''.
...
> >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].
> >> The cause has to be a signal on one of the IRQ lines enabled by FreeBSD
> >> (because masked lines are completely ignored). The signal can then interfere
> >> with the signal from the enabled board.
>
> >Mostly true, ``(because masked lines are completely ignored)'' in not
> >technically accurate, the mask register and AND gate are after the IRR latch,
> >but they can't cause the priority resolver to trigger an INT request at
> >step 2 above, so they should be out of the picture from a software point.
>
> Oops. Yes, they are only ignored for the purpose of generating interrupts.
>
> >Do we ever use the value of the IRR to dispatch an interrupt? As the IRR
> >can be set even though the mask bit is turned on.
>
> We only use it to determine if a clock interrupt has just occurred in
> microtime(). It's too expensive to read it on the chance that it might
> be set becuse the chance isn't high (except possibly after interrupts
> have been masked for a long time) and it takes too long to read (about 1
> usec). It is only of much use for examining the state of unacknowledged
> (necessarily masked) interrupts - then it follows the real-time IRQ
> signals. For acknowledged interrupts, it suffers from edge triggering
> braindamage - it is 0 from when you send EOI until the next rising edge
> on the IRQ, so reading it doesn't tell you if the IRQ is still there.
>
> Bruce
>
--
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?199604051715.JAA08863>