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
 ã ú