Thank you very much Bob for providing information on issues with using “int”
for faking interrupts.
On 3/21/07, Bob Kjelgaard wrote:
>
>
>
> Jake is pointing out that the core OS interrupt handling for known
> hardware interrupts deals with real hardware (multiple pieces of it), and
> you’ve only focused on the processor.
>
> Now I haven’t dealt directly with an interrupt controller in almost 20
> years (sad to say, because I really liked it when I did that sort of thing),
> but it is a piece of hardware that owns making sure device interrupts get
> processed, and also typically manages their priority.
>
> There was a thread here a while back in which I participated that began
> with OP claiming that it was impossible for asynchronous events like
> interrupts to be processed with absolute reliability. I replied that that
> is why hardware /software handshakes are used. I believe I avoided going on
> to say that interrupt controllers are the hardware piece that does this, but
> that is indeed their purpose in life?
>
> Basically, when the processor has “handled” an interrupt, it sends a
> command /signal “end of interrupt”, or EOI to the interrupt
> controller. This process of the controller getting an interrupt indication
> from a device, then presenting it the processor in approved fashion, and
> then presenting the next when the previous one is handled, is the sort of
> handshake I was alluding to. This level of handshake is in addition to the
> one you still typically manage where your ISR has to clear a condition in
> your device, or otherwise notify the device the interrupt is being handled.
>
> In more primitive OS (such as the venerable DOS, and typically still today
> in most BIOS) each device driver for an interrupting device does this
> explicitly in its ISR.
>
> But NT streamlined and simplified this by abstracting IRQL, and it always
> sends the EOI itself in addition to calling the ISR chain for that
> vector. This makes drivers easier because the OS (typically the HAL) now
> owns understanding how exactly you do this. In those old glory days, you
> could spend a fair amount of design time and rework time in a driver if
> someone changed controllers, or their I/O address, or command/register set,
> etc. With the HAL, you don’t need to care- usually, as perhaps demonstrated
> here, you don’t even know it happens.
>
> So the short of it is that you have triggered the interrupt routine for a
> known hardware interrupt. By this logic, and EOI has to be sent- Jake is
> pointing out a side effect of your approach that you probably did not
> consider.
>
> The exact effect this has depends upon details of the controller. Current
> systems usually use the APIC, which I have not studied in sufficient detail
> to say I can claim with absolute certainty that it will cause some other
> interrupt to be missed or improperly handled EVERY time, but I do know that
> it is a potential and likely problem [it can definitely happen SOME of the
> time], which is enough for me to agree that this is not a safe way to deal
> with this problem. Besides, the whole idea is that you only need ONE
> controller where this screws you for this to be a problem that breaks you
> mysteriously on some hardware [even the sort of thing where different
> production dates of the same model or motherboard behave differently, for
> instance]. I suppose if one is an absolute expert on every interrupt
> controller model in use or likely to be in use over the lifetime of your
> driver, you can push the envelope safely, but I’d rather err on the side of
> safety.
>
> I’m sure Jake and others here have more current and detailed info
> available wrt the APIC and other current generation controllers, but I can
> confidently assert for these reasons that the basic problem he has presented
> is a real, reasonable and valid objection to this approach.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>