Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!imagen!qmsseq!pipkins
From: pipkins@qmsseq.imagen.com (Jeff Pipkins)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Hardware interrupts, IRQ7, and Burr-Brown PCI 20098C
Message-ID: <60@qmsseq.imagen.com>
Date: 4 Dec 89 19:21:24 GMT
References: <2460@draken.nada.kth.se>
Reply-To: pipkins@qmsseq.UUCP (Jeff Pipkins)
Organization: QMS Inc., Mobile, Alabama
Lines: 29

WARNING: WHEN WRITING AN ISR FOR IRQ7, YOU MUST BE CAREFUL TO HANDLE GLITCHES!

The 8259 Programmable Interrupt Controller used in ATs has 8 channels numbered
0-7.  But aside from the priorities, line 7 still has one major difference
from the rest that should be noted.  Any time the 8259 detects a glitch
(or a request that is too short) on ANY OF THE LINES, it will generate
a synthesized interrupt on IRQ7.  Your ISR can tell whether it's a real
interrupt or a glitch by checking bit 7 of the In Service Register.
Same precautions apply for IRQ15, since this is on channel 7 of a second
(cascaded) 8259.  (As an added bonus, the HP Vectra has THREE 8259s,
although I can't figure out why?!)
If your interrupt service routine is invoked by a glitch, you must NOT
issue an EOI before IReturning.

IntService:
	     <Save Regs>
	     Mov AL, 0Bh
	     Out 20h, AL
	     Jmp Short $+2 ; See related thread...
	     In AL, 21h ; Read the ISR
	     Test AL, 80h  ; Bit 7 on?
	     Jz IReturn    ; If not on, jump to IRet instruction
	     <continue...>

I hope the numbers here are right; I've got the book in front
of me, but my newsreader won't let me look at my code right now.
I think this is right, though.  This code is IRQ7 specific.

Hope this helps.