PCI Interrupts - solved

[Allen Marshall <AllenMa@Attachmate.com>]

All:

Ken Cooper had the answer; I wasn't de-asserting the h/w int in my
handler, causing the handler to be called so much it overflowed the
stack. 

Many thanks to all who responded (esp. Ken!).

Regards,

==================
Allen Marshall
Sr. Design Engineer
Attachmate Corp.
Hardware Engineering
(206) 644-4010 x4206
email: allenma@atm.com


>----------
>From: 	Allen Marshall <AllenMa@attachmate.com>
>Sent: 	Wednesday, January 15, 1997 12:38 PM
>To: 	Mailing List Recipients <pci-sig-request@znyx.com>
>
>I'm having trouble with some code for testing interrupts on a PCI
>adapter. I have verified that electrically the interrupts are firing
>properly; the trouble shows up in my int handler. This program is a just
>a DOS app to verify our adapter's functionality, and it also supports an
>ISA version of the same type of adapter. The ISA adapter is hardwired to
>IRQ 2(9), and both adapters call the exact same code routine - and the
>ISA version runs just fine. Also, this problem is limited to PCs with
>(apparently) older BIOS; I have tested it on several newer machines
>without a glitch.
>
>All I'm doing is (in pseudo-code):
>
>	getIRQ_Setting ();		// get settings from Config Space Header
>	disable ();			// disable ints
>	InstallMyHandler ();		// hook proper vector
>	enable ();			// enable ints
>	clearPIC_IMR ();			// make sure proper IRQ is enabled in PIC
>	makeAdapterFireInt ();		// go for it
>	make sure to leave enough time here...
>	checkFlag ();			// did we make it?
>	clearAdapter'sInt ();		// clear the adapter's INT line
>
>And for this test, all the Int handler is doing is:
>
>	setFlag ();			// just like it says
>	oldHandler ();			// chain to old int handler
>	sendEOI ();			// send EOI to Master, Slave, or both PICs as needed
>
>When the int handler is called the PC dies with an "internal stack
>overflow" error.
>
>The PIC on dying machines seems to be behaving differently than on
>working machines...when I fire the int, I see the appropriate bit set in
>0xA0  - that is , if I'm assigned IRQ10, the the slave PIC asserts 0x04
>when I set my hardware int, and clears when I clear my adapter's int.
>Other machines don't behave this way (and they work!).
>
>I've tried tons of things - not chaining to the old handler, stripping
>my code down to a bare minimum, etc. I'm stuck - any insight would be
>greatly appreciated.
>
>
>==================
>Allen Marshall
>Sr. Design Engineer
>Attachmate Corp.
>Hardware Engineering
>(206) 644-4010 x4206
>email: allenma@atm.com
>
>	
>
>
>.
>
ådQ