Date: Thu, 4 Apr 1996 23:36:02 -0800 (PST) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: bde@zeta.org.au (Bruce Evans) Cc: nate@sri.MT.net, current@FreeBSD.org, jgreco@brasil.moneng.mei.com, root@deadline.snafu.de Subject: Re: tty-level buffer overflows - what to do? Message-ID: <199604050736.XAA08401@GndRsh.aac.dev.com> In-Reply-To: <199604050346.NAA15285@godzilla.zeta.org.au> from Bruce Evans at "Apr 5, 96 01:46:05 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> >> This is a pretty good indication that something is mis-confugred. IRQ 7 > >> is the 'junk' interrupt, which means it gets all of the interrupts not > >> otherwise assigned to a particular piece of hardware. Something is > >> generating interrupts on your system bogusly and you need to find out > >> what. > > >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. 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. 4. Upon receiving an INTA~ from the CPU group, the high- est priority ISR bit is set and the corresponding IRR bit is reset. The 8259A does not drive the Data Bus during this cycle. .... If no interrupt request is present at step 4 of either sequence (i.e., the request was too short in duration) the 8259A will issue an interrupt level 7. Both the vectoring bytes and the CAS lines will look like an interrupt level 7 was requested. [Here is more info on page 2-101 about the above, even closer to what I stated:] 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. > > >Often the cause of stray IRQ7's is noisy or floating IRQ signals from boards > >that are not recognized by FreeBSD. > > 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. 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. -- 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?199604050736.XAA08401>