[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: DOS PCI and Interrupts



Eric,

Thanks for the feedback. I thought that was the way to go.

Mike

-----Original Message-----
From: Eric de Jong [mailto:info@simultime.nl]
Sent: Monday, June 03, 2002 12:22 AM
To: Mike Berkowitz
Cc: pci-sig@znyx.com
Subject: Re: DOS PCI and Interrupts


Level triggered interrupts are easier from a software point of view. If you
forget to
handle it because of a race condition, a new irq wil be generated
automatically as
long as your hardware keeps your irq line asserted.

Your interrupt subroutine (isr) is a normal chained isr case I guess. I
would think
of something like this:
1) test if your hardware needs servicing
2) disable interrupt request on your hardware
3) call old isr
4) handle PIC (may be done by 3, the old isr, but who cares)
5) iret

at point 4) or 5), are interrupts are/may be enabled. If they are, isr calls
will be
nested under race conditions or heavy load. This is not a problem. For
extreme heavy
load, this can eventually lead to a stack overflow. However, if this
occures, this
means your system is too slow to handle your isr. This should never happen
as your
isr should be as quick as possible. The actually data processing should
happen in
your main program.

if point 3) and 4) are swapped, your card will get priority over the 'old'
isr
vector: when your card generates another irq before the 'old' vector was
handled your
isr get handled first because you re-enabled the PIC (nested interrupt).
This should
not be a problem, but it does implies that if another driver does the same
and calls
YOUR driver, the PIC is enabled and you can get an irq from your card while
still
handling the previous irq. So make sure to block interrupts on your PC while
processing your hardware.

Eric.

----- Original Message -----
Thank you for your reply.

Fortunately, I have written DOS Interrupt Service Routines before. However,
ISA interrupts are edge triggered. It is easy to see and clear interrupts.
With level triggered interrupts I am worried about knowing if another
interrupt has occurred while I was in my handler. Specifically, I am worried
that if the two boards sharing an interrupt are both under heavy load, that
a race condition could exist. The way I see this happening is when My
handler re-enables interrupts after it sends the INTACK to our interrupting
PCI device and then re-setting the PIC. If another card had asserted an
interrupt won't the PIC generate an interrupt before my handler and issue an
IRET?


Mike