- Higer IRQL interrupt can preempt other lower IRQL interrupt?
- Posted by Daniel on September 15th, 2003
Hi,
A basic question just to confirm a point:
In Windows, Is It true that higer IRQL interrupt can
preempt other interrupt with lower IRQL and all the
interrupts with IRQL equal to or below current IRQL will
be masked and wait until they get an opportunity?
Thanks,
Daniel
- Posted by Walter Oney on September 15th, 2003
Daniel wrote:
Yep.
--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com
- Posted by Andreas Hansson on September 15th, 2003
"Walter Oney" <waltoney@oneysoft.com> skrev i meddelandet
news:3F65FE73.11046D4B@oneysoft.com...
Seeing how this prioritizing of devices sounds like a nice feature, is
there any good way that you can request to have a "higher" or "lower"
interrupt IRQL? For example it might be good for my sound card to have a
higher IRQL than my network card so intense network traffic no longer
causes break-up of sounds playing?
Andreas
- Posted by Neill Clift [MSFT] on September 15th, 2003
"Walter Oney" <waltoney@oneysoft.com> wrote in message
news:3F65FE73.11046D4B@oneysoft.com...
You have to be carefull here. We have a software interrupt
thats below DISPATCHER_LEVEL so you can get context
swapped even though you are running above
PASSIVE_LEVEL. The level in question is APC_LEVEL.
This makes this s/w interrupt level sort of thread local. You
block APC's by raising to this level only in the current thread
because you could be context swapped away from the
thread to a thread running at PASSIVE_LEVEL that
could then take an APC interrupt.
Neill.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
- Posted by Ray Trent on September 15th, 2003
That's a slightly oversimplified answer. On a multiprocessor machine
(including single Intel HTT CPUs that act like MPs), a lower IRQL
interrupt is not masked on the other processor.
Walter Oney wrote:
--
.../ray\..
- Posted by Mark Roddy on September 15th, 2003
On Mon, 15 Sep 2003 20:16:34 +0200, "Andreas Hansson"
<andreas.msnews@nsp1.adron.org> wrote:
No, not in the current releases of NT. What you get is what you get,
deal with it.
=====================
Mark Roddy
Windows XP/2000/NT Consulting, Microsoft DDK MVP
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com
For Windows Device Driver Training: see www.azius.com
- Posted by Alexander Grigoriev on September 16th, 2003
The ISR runs under an interrupt spinlock, and I think you can change IRQL
under which it runs. You won't change IRQL of the IRQ line, though, so it
won't give the physical interrupt line higher priority.
So the answer is: you can prevent your ISR from being interrupted, by giving
it higher IRQL, but you cannot change the interrupt line priority.
"Mark Roddy" <mroddy@tellink.net> wrote in message
news:amhcmvkq302vc7svogp2uj8bognjdl46uc@4ax.com...
- Posted by Maxim S. Shatskih on September 16th, 2003
IMHO, but the "interrupt priority" idea is due to stupidity of the 8259
interrupt controller.
What is the conceptual need of masking some interrupts off while executing this
particular interrupt? Why masking this particular interrupt only is not enough?
It is enough to implement KeSynchronizeExecution.
Why raising to DIRQL 10 must mask away IRQ 9? Why not allow the device on IRQ 9
to interrupt the ISR of IRQ 10?
Maybe APIC allows such a mode, when all interrupts are always unmasked while
handling this particular interrupt?
Correct. If there would be a way of governing the IRQL for drivers, then all
driver writers would make their drivers to use the highest IRQL, so, the
feature would be useless.
Usual PCs work fine regardless of the IRQLs Windows gave to hardware. Even IDE
CD-ROM in PIO mode, which is the most renowned "spender of time in the ISR",
will coexist with sound card with high latency requirements.
It extemely depends on motherboard, for instance, it is wrong for systems with
APIC.
This must work on non-APIC non-ACPI systems.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
- Posted by Pavel A. on September 17th, 2003
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:%23a9rNkIfDHA.2408@TK2MSFTNGP09.phx.gbl...
This is because NT adopted the interrupt handling logic from DEC machines, that have (had...) IRQ
priority independent from IRQ vector. The OS can assign any of four IRQLs to any interrupt source.
And if you want to sync two ISRs, you just assign same IRQL to their interrupt sources - zero
software overhead.
In order to get this flexibility from the stupid 8259 PIC, you need to mask all IRQs whose IRQL is
less or equal to currently active interrupt. When the ISR returns, the correspondent level is
unmasked in the either PIC (master or slave).
If memory serves, in NT4 there was "lazy 8259 masking" optimization: the actual write to 8259 mask
register did not even occur if interrupts of these levels didn't arrive.
dunno about APIC: it just works so why bother to rtfm...
Regards,
-PA
