You asked for an evaluation....
I wish that Jose had talked to me, or somebody who actually works on the
code, before he wrote that. He missed some pretty fundamental points.
First let me say, as I have said in the past in this forum, calling
IoConnectInterrupt with an IRQL other than that which you were handed by
the PnP manager will only result in a machine that either fails to
connect your interrupt or a machine that will eventually deadlock
Second, let me say that you can only run HALMPS.dll on machines with an
MPS BIOS. And, if your machine has one of those, HALMPS.dll will be
installed by default. So replacing your HAL will probably result in a
machine that doesn't boot. (Furthermore, in Windows 2000, Windows XP
and Windows .Net Server, we'll probably install halmacpi.dll, which is
similar to halmps.dll, except that it works with an ACPI BIOS.)
As for the article, Jose's most egregious misunderstanding is that he
thinks that IRQL is meaningless on uniprocessor systems. It's not.
It's exactly the same thing that it is on multi-processor systems, a way
to assign a priority level to a processor.
What Jose got tripped up on is something that we call "Lazy IRQL." This
is a way to avoid writing to the control registers on the 8259 PIC
Interrupt Controller, which is usually in a part of the machine that
takes a long time to send I/O cycles to.
In a "Strict IRQL" system, when we take an interrupt, we raise IRQL to
the appropriate level (which involves writing to the interrupt
controller) before we issue a "sti" instruction, which re-enables
interrupts at the processor. Thus we are guaranteed that we will never
execute any code that is of a lower priority until we finish running the
appropriate ISR and lower IRQL.
In a Lazy IRQL HAL, we take advantage of the fact that most interrupts
don't overlap with other interrupts. Instead of writing to the
interrupt controller, we merely note that a change of IRQL should have
occurred. Then we call the ISR for the device, even though
lower-priority interrupts aren't masked. If one of those interrupts
happens before we finish the first device's ISR, then the interrupt
pre-amble code will note that we have just taken an interrupt that
should have been masked, actually mask the interrupt controller and
dismiss the errant interrupt without ever calling that second device's
ISR. Then, when the first device's ISR completes, we go back and run
the second device's ISR at the correct lower IRQL.
This system maintains all the semantics of the Strict IRQL system, but
does many fewer writes to the interrupt controller. At present, we only
do Lazy IRQL in hal.dll, which is the default single-processor non-ACPI
HAL. All the other HALs use Strict IRQL.
Please ignore most of Jose's conclusions, as they are based on these
NT Kernel Team
This posting is provided "AS IS" with no warranties, and confers no
Subject: Device Interrupt priority & Extreme ISR Priority : new thread
From: "Christiaan Ghijselinck" <xxxxx@Compaqnet.be>
Date: Sun, 8 Dec 2002 09:33:59 -0500
Could someone please evaluate the article of Jose Flores at http://www.joseflores.com/docs/ExploringIrql.html
Assuming that the information is correct, may I then conclude that on a
multiprocessor system, an ISR connected through IoConnectInterrupt ( ...
POWER_LEVEL , ...) ; will :
- never be suspended by another IRQ
- always suspend ( preempt ) running lower priority ISR's
If I install the MPS version on a monoprocessor system, does the
installation revert to the mono processor HAL.ddl or may I profit from
multiprocessor version ( halmps.dll ).