Date: Sat, 6 Apr 1996 01:51:01 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, rgrimes@GndRsh.aac.dev.com Cc: 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: <199604051551.BAA12866@godzilla.zeta.org.au>
next 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).
>1985 Intel Microsystems Components Handbook, page 2-93:
>Interrupt Sequence
>...
>The events occur as follows in an MCS-80/85 system:
>1. One or more of the INTERRUPT REQUEST lines
> (IR7-0) are raised high, setting the corresponding IRR
> bit(s).
>2. The 8259A evaluates these requests, and sends an
> INT to the CPU, if appropriate.
>3. The CPU acknowledges the INT and responds with an
> INTA~ pulse.
>The events occurring in an iAPX 86 system are the same until step 4.
Step 3 isn't reached if the interrupt occurs and goes away while
interrupts are disabled. I've watched this many times (e.g. by
reading the IRR in a debugger), and turned off the interrupt source
directly - the interrupt doesn't occur.
>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.
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604051551.BAA12866>