Return to BSD News archive
Newsgroups: comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!munnari.oz.au!foxhound.dsto.gov.au!fang.dsto.gov.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!news.cs.su.oz.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!netcomsv!calcite!vjs
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Subject: Re: Info on IRQs needed
Message-ID: <CvL1Cz.Ips@calcite.rhyolite.com>
Organization: Rhyolite Software
Date: Sun, 4 Sep 1994 01:55:47 GMT
References: <CvIx4u.4Lx@nanguo.cstpl.com.au>
Lines: 28
In article <CvIx4u.4Lx@nanguo.cstpl.com.au> earth@nanguo.cstpl.com.au (Bob Chalmers) writes:
>In the March 1992 issue of Dr Dobbs Journal, page 46, figure #1,
>the authors have a foot note thus;
>
>*IRQ7 and IRQ15 also receive "lost" interrupts for associated controller.
>
>What do they mean? Can someone describe what is happening here for an
>interrupt to be "lost". Unfortunatly the article does not.
Say an interrupt request signal to an Intel 8259A Interrupt Control
appears, the 8259A starts to chitchat with the CPU, and the interrupt
request signal goes away before the 8259A has a chance to deliver the
vector of the interrupt or the number if polling. In this case the
8259A will say "7" to the CPU.
The following text under the heading "Interrupt Sequence" about 7
pages into your favorite version of the 8259 data sheet is probably
more clear than my explanation:
"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."
If you're careful about when you do things to hardware with interrupts
turned on, or if you take just a little care to deal with stray interupts,
this is not a significant problem.
Vernon Schryver vjs@rhyolite.com