Hello all!
As I know, all hardware interrupts are queued and the OS processes
them one by one from the most significant (with the highest IRQL) down
to the less significant (with the lowest IRQL).
But I don’t understand clearly how does this mechanism work. Could
you please give me an answer or refer to the source where I can read
about that stuff? For instance, what if the device, emitted an
interrupt, changed its state and when its event will be unqueued the
data/status of that device will be old?
MA
“Michael Alekseev” wrote in message
news:xxxxx@ntdev…
>
>
> But I don’t understand clearly how does this mechanism work. Could
> you please give me an answer or refer to the source where I can read
> about that stuff? For instance, what if the device, emitted an
>
If you’re looking for a primer on how the hardware interconnects, and some
of the very basics about Windows, check out the article on this topic from
last month’s issue of The NT Insider
https://www.osronline.com/article.cfm?id=211 (you’ll need to subscribe, but
it’s free so…).
If you’re looking for more detailed information about how Windows handles
interrupts, you can search the archive for postings by Jake Oshins (the MS
dev who does a lot of the HAL/interrupt work). The easiest way to do to
search the archive is by going to www.osronline.com, and from the search box
on the home page (select “NTDEV” from the drop down on the left, and put the
search term in the box… or better yet, use this link:
http://www.osronline.com/custom.cfm?name=index_fullframeset.cfm&pageURL=http%3A%2F%2Fwww.osronline.com%2Ftexis.exe%2Fwebinator%2Fsearch%2F&pr=ntdev).
HTH,
Peter
OSR
For the first question – how does it work – I recommend Volume 3, Chapter
8:
http://developer.intel.com/design/pentium4/manuals/
For the second question – what if my device didn’t latch the reason for the
interrupt, and by the time my ISR is called, the state is gone – I submit
that your device is so poorly designed that you probably won’t ever get it
to work. You need to latch the reason for the interrupt. You also need a
deterministic way to mask that particular reason.
–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no rights.
OR if you wish to include a script sample in your post please add “Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm”
“Michael Alekseev” wrote in message
news:xxxxx@ntdev…
>
> Hello all!
>
> As I know, all hardware interrupts are queued and the OS processes
> them one by one from the most significant (with the highest IRQL) down
> to the less significant (with the lowest IRQL).
> But I don’t understand clearly how does this mechanism work. Could
> you please give me an answer or refer to the source where I can read
> about that stuff? For instance, what if the device, emitted an
> interrupt, changed its state and when its event will be unqueued the
> data/status of that device will be old?
>
> MA
>
>
>
>
>
Hello Peter,
Thank you for assistance!
Michael
PV> “Michael Alekseev” wrote in message
PV> news:xxxxx@ntdev…
>>
>>
>> But I don’t understand clearly how does this mechanism work. Could
>> you please give me an answer or refer to the source where I can read
>> about that stuff? For instance, what if the device, emitted an
>>
PV> If you’re looking for a primer on how the hardware interconnects, and some
PV> of the very basics about Windows, check out the article on this topic from
PV> last month’s issue of The NT Insider
PV> https://www.osronline.com/article.cfm?id=211 (you’ll need to subscribe, but
PV> it’s free so…).
PV> If you’re looking for more detailed information about how Windows handles
PV> interrupts, you can search the archive for postings by Jake Oshins (the MS
PV> dev who does a lot of the HAL/interrupt work). The easiest way to do to
PV> search the archive is by going to www.osronline.com, and from the search box
PV> on the home page (select “NTDEV” from the drop down on the left, and put the
PV> search term in the box… or better yet, use this link:
PV> http://www.osronline.com/custom.cfm?name=index_fullframeset.cfm&pageURL=http%3A%2F%2Fwww.osronline.com%2Ftexis.exe%2Fwebinator%2Fsearch%2F&pr=ntdev).
PV> HTH,
PV> Peter
PV> OSR
PV> —
PV> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
PV> You are currently subscribed to ntdev as: xxxxx@nadatel.com
PV> To unsubscribe send a blank email to xxxxx@lists.osr.com
Hello Jake,
Do you meant that this reason is depending only on a device itself?
And if the device is properly designed and implemented this sutiation
shouldn’t be possible?
Regards,
Michael
JO> For the second question – what if my device didn’t latch the reason for the
JO> interrupt, and by the time my ISR is called, the state is gone – I submit
JO> that your device is so poorly designed that you probably won’t ever get it
JO> to work. You need to latch the reason for the interrupt. You also need a
JO> deterministic way to mask that particular reason.
I’m sorry. I don’t completely understand your question. Could you explain
further?
–
Jake Oshins
Windows Base Kernel Team
This posting is provided “AS IS” with no warranties, and confers no rights.
OR if you wish to include a script sample in your post please add “Use of
included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm”
“Michael Alekseev” wrote in message
news:xxxxx@ntdev…
>
> Hello Jake,
>
> Do you meant that this reason is depending only on a device itself?
> And if the device is properly designed and implemented this sutiation
> shouldn’t be possible?
>
> Regards,
> Michael
>
> JO> For the second question – what if my device didn’t latch the reason
for the
> JO> interrupt, and by the time my ISR is called, the state is gone – I
submit
> JO> that your device is so poorly designed that you probably won’t ever
get it
> JO> to work. You need to latch the reason for the interrupt. You also
need a
> JO> deterministic way to mask that particular reason.
>
>
>
>
>
(a bit simplified description)
The mechanism is mainly the interrupt controller hardware, be it PIC or
APIC.
The INT line raise from a lower-IRQ device will not be delivered to the CPU
till it is running in the ISR code for a higher-IRQ device.
On return from the driver’s ISR, the kernel will call HalEndSystemInterrupt
function, which pings the interrupt controller, thus saying it that the ISR is
complete. At this very moment, another IRQ can be delivered to the CPU.
The main show-spoiler here is IDE CD drive in PIO mode. It does all its
data pump as REP INSW in the ISR routine, thus starving other IRQs.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Michael Alekseev”
To: “Windows System Software Developers Interest List”
Sent: Friday, August 29, 2003 6:11 AM
Subject: [ntdev] IQR processing
> Hello all!
>
> As I know, all hardware interrupts are queued and the OS processes
> them one by one from the most significant (with the highest IRQL) down
> to the less significant (with the lowest IRQL).
> But I don’t understand clearly how does this mechanism work. Could
> you please give me an answer or refer to the source where I can read
> about that stuff? For instance, what if the device, emitted an
> interrupt, changed its state and when its event will be unqueued the
> data/status of that device will be old?
>
> MA
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Hello Maxim,
Thanks a lot! Everything is clear now.
Can you advise me a book that concentrates mainly on HAL routines and
its(HAL’s) overall work? The books like Programming WDM or Windows
2000 Device Driver Book contain a few information about this kernel
component.
Michael Alekseev
Wednesday, September 3, 2003, 1:58:45 AM, you wrote:
MSS> (a bit simplified description)
MSS> The mechanism is mainly the interrupt controller hardware, be it PIC or
MSS> APIC.
MSS> The INT line raise from a lower-IRQ device will not be delivered to the CPU
MSS> till it is running in the ISR code for a higher-IRQ device.
MSS> On return from the driver’s ISR, the kernel will call HalEndSystemInterrupt
MSS> function, which pings the interrupt controller, thus saying it that the ISR is
MSS> complete. At this very moment, another IRQ can be delivered to the CPU.
MSS> The main show-spoiler here is IDE CD drive in PIO mode. It does all its
MSS> data pump as REP INSW in the ISR routine, thus starving other IRQs.
MSS> Maxim Shatskih, Windows DDK MVP
MSS> StorageCraft Corporation
MSS> xxxxx@storagecraft.com
MSS> http://www.storagecraft.com
“Michael Alekseev” wrote in message
news:xxxxx@ntdev…
>
> Hello Maxim,
>
> Can you advise me a book that concentrates mainly on HAL routines and
> its(HAL’s) overall work? The books like Programming WDM or Windows
>
There IS no book that concentrates on the HAL, or that discusses much of the
details of how interrupts are handled in Windows. In fact, to be perfectly
correct about it, (and just for the purpose of basic information) much of
the functions that once took place in the HAL aren’t even IN the HAL
anymore – they’re in the kernel, the I/O Manager, the PnP Manager, and the
various drivers that comprise the bus subsystem.
A book on these aspects of Windows would be interesting, but it would be
hard to write and what would the market be? Heck, there’s not even a book
on NDIS…
Peter
OSR
Well you could charge $6,000 a copy, have lots of big glossy diagrams, and
ship it with its own carved reading stand. Quite the conversation piece for
one of those retro .net boomtime nerd nostalgia parties.
=====================
Mark Roddy
-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Thursday, September 04, 2003 9:20 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] Re: IQR processing
“Michael Alekseev” wrote in message
> news:xxxxx@ntdev…
> >
> > Hello Maxim,
> >
> > Can you advise me a book that concentrates mainly on HAL
> routines and
> > its(HAL’s) overall work? The books like Programming WDM or Windows
> >
>
> There IS no book that concentrates on the HAL, or that
> discusses much of the details of how interrupts are handled
> in Windows. In fact, to be perfectly correct about it, (and
> just for the purpose of basic information) much of the
> functions that once took place in the HAL aren’t even IN the
> HAL anymore – they’re in the kernel, the I/O Manager, the
> PnP Manager, and the various drivers that comprise the bus subsystem.
>
> A book on these aspects of Windows would be interesting, but
> it would be hard to write and what would the market be?
> Heck, there’s not even a book on NDIS…
>
> Peter
> OSR
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
“Roddy, Mark” wrote in message news:xxxxx@ntdev…
>
> Well you could charge $6,000 a copy, have lots of big glossy diagrams, and
> ship it with its own carved reading stand. Quite the conversation piece
for
> one of those retro .net boomtime nerd nostalgia parties.
>
Can I put you down for a bunch of copies? You could send them out as Xmas
gifts to your clients??
P