RE: Device Interrupt priority - Reviewing Jose Flores

Yes, both are true. But, for charts, let me point out that the built in
priority scheme on the 8259 PIC doesn’t have anything to do with IRQL.

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
Subject: RE: Device Interrupt priority - Reviewing Jose Flores
From: “Christiaan Ghijselinck”
Date: Mon, 9 Dec 2002 18:27:00 -0500
X-Message-Number: 35

Thanks for the reply Jake,

You wrote :

> 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.

As for my understanding, may I conclude that higher level IRQ’s DO
interrupt the running ISR and will run to the end, after which the
current
interrupted ISR will continue ? Does this mean that the 8259 PIC’s IRQ
priority handling is programmed/reprogrammed on the fly by the OS to
match
the IRQL of the ISR’s in the system ?

You’re right. I owe you an apology. A careful re-reading of your
article shows that you did understand the code.

I still think that the first half of your article makes little
distinction between taking an interrupt and calling a device driver’s
ISR. I believe that the difference between the two is meaningless to
most of the readers of this list. And it should be made very clear that
NT will never pre-empt a high-IRQL ISR with a low-IRQL ISR. It will
also never violate the locking semantics that are supported through the
concept of IRQL.

I don’t think that the fact that an interrupt is actually enabled or
disabled at the interrupt controller has much relevence in this context.
I don’t mean to say that you shouldn’t be interested in how things are
implemented. I just mean that you should be careful how you present
this, since I believe it clouded at least one reader’s overall
understanding.

  • Jake

-----Original Message-----
Subject: RE: Device Interrupt priority - Reviewing Jose Flores
From: “Jose Flores”
Date: Mon, 9 Dec 2002 19:05:47 -0500
X-Message-Number: 36

Couple of things:

[1] Nowhere in that article does it recommend calling
IoConnectInterrupt()
w/ a made up IRQL. Nor does it advocate yanking & replacing hals out
from
underneath the installation.

The point of the article was (1) to give a peek at what goes on under
the
hood of IRQL manipulation and (2) to illustrate that raising IRQL does
not
always deny interrupts associated with lower priority IRQLs to fire. I
don’t think it’s a stretch do assume that most people take for granted
that if they raise to SYNCH that practically no interrupts will fire.
This is clearly not the case on UP systems. On such a hal, ALL
interrupts
will fire (initially), but the subsequent execution of NT’s interrupt
stub
will prevent the clients ISR from running until IRQL is lowered to an
acceptable level.

No doubt that this subtly hardly matters to anyone, except maybe a
handful
of people who are either doing seriously funky (most likely
non-production
quality) work, or are just morbidly curious.

[2] Nowhere in the article does it state that IRQL is meaningless on
uniprocessor systems. In fact it does describe what you call “Lazy
IRQL”.
From the article (edited for brevity):

“why do we use it (IRQL) at all on uniprocessor systems?..the NT kernel
performs explicit checks of the IRQL value at key points in it’s
execution…”

“…If the vector’s IRQL is less than or equal to the currently
executing
code’s IRQL, then everything is undone, the processor’s context is
restored, and control is returned to the interrupted code. … In cases
where the interrupt is dismissed, variables inside the PCR are used to
mark the particular interrupt vectors as having had an interrupt fire
that
was not completely serviced. … dismissing the interrupt is usually
followed with actually masking the particular interrupt in hardware to
prevent further execution of the ISR until the pending interrupt can be
serviced completely.”

“Each time IRQL is dropped, a check is performed to see if there are any
‘pending’ interrupts. If so, then a software interrupt is issued (after
the IRQL is dropped) corresponding to the vector to which the hardware
interrupt is mapped. For example, if the clock interrupt is mapped to
vector 0x30 with an IRQL of 0x1C, then if the current IRQL is dropping
from 0x1F to 0x2, then … The ISR executes as normal, and the
interrupt is
now completely serviced. The pending bit is cleared, and the interrupt
is
unmasked.”

Granted the article wasn’t privy to more colorful insider descriptions
such as Lazy and Strict IRQL, but the end description is essentially the
same. Likewise, what the article calls an interrupt stub, you call a
preamble. Tomato, tomato.

Maybe the unfinished article was poorly written to have anyone to
conclude
that the article suggests the above. Or maybe it just wasn’t read in
the
right frame of mind. Either way, I’d be interested in hearing
criticisms
privately from someone with your inside knowledge.

“Jake Oshins” wrote in message
news:xxxxx@ntdev…

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
itself.

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
misunderstandings.

Jake Oshins
NT Kernel Team
Microsoft

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
Subject: Device Interrupt priority & Extreme ISR Priority : new thread
From: “Christiaan Ghijselinck”
Date: Sun, 8 Dec 2002 09:33:59 -0500
X-Message-Number: 2

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
the
multiprocessor version ( halmps.dll ).

----------------------------------------------------------------------

Subject: Re: Writng and Debuging Drivers in C++
From: “David J. Craig”
Date: Mon, 9 Dec 2002 19:02:25 -0500
X-Message-Number: 37

I think MSDN is required for someone in the development group to have
available. You can get the DDKs for “free” if you have one. I have
also
found that keeping the old DDKs, SDKs, and operating systems to be
necess=
ary
because most of the world isn’t switching as quickly as Microsoft would
like. There is the archive pack with some of the old stuff too. I have
found that some documentation disappears if you don’t have access to the
older versions. Also there is one hardware “requirement” that OSR
advise=
s
and that is a 8x SMP system. Some deadlocks and other SMP issues may
not
show up quickly on a single CPU or a dual processor. I remember
releasin=
g
one driver that had the no-SMP flag set. We didn’t have a SMP system to
test and the risk to our partners was deemed too high. I have been at a
company where only one or two of the systems had DVDs. Every other
syste=
m
had CD-ROMs only. I prefer the paychecks get paid instead of having all
=
the
toys I want, but I still want the toys.

I think that using the checked builds of the HAL and Kernel is required
t=
o
drivers stable. I don’t think that you need the entire checked OS for
drivers, but you may want it for some applications.

----- Original Message -----
From: “Chris Dor=E9”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Monday, December 09, 2002 5:34 PM
Subject: [ntdev] Re: Writng and Debuging Drivers in C++

> >
> > It is expensive and Microsoft has not done much itself to reduce
cost=
s.
> > Windbg is “free”, but you still have to download it. Just printing
t=
he
> user
> > guide will chew up most of a ream of paper. MSDN is absurdly
expensi=
ve
> and
> > appears designed to limit the ability to develop to those who have
de=
ep
> > pockets. MSDN Universal costs more than the two computers you need
t=
o
> write
> > drivers. Add in the IFS Kits and you need $10,000 just to start in
t=
he
> > first year. Remember when many shareware developers could write
usef=
ul
> > utilities, TSRs, and drivers for MS-DOS with little or no expense
exc=
ept
> the
> > hardware. The costs seem to have shifted from hardware to software.
=
I
> just
> > read that Microsoft has said that its costs for their operating
syste=
ms
is
> > only $0.15 or $0.16 per dollar charged. Nice margins!
> >
>
> You do not, by any means, need an MSDN subscription to develop device
> drivers. If you have access to the internet then you’re completely
set.
The
> DDK is practically free (just pay for the shipping), and the entire
MSD=
N
> library is available for free on Microsoft’s website. The DDK comes
wit=
h a
> compiler and everything you need to build a driver…in fact you don’t
> really even need access to the internet (of course access to the
extr=
a
> information is quite a help).
>
> Now there are some useful things lacking from not having a MSDN
> subscription, like checked OS builds, but I have actually never used
th=
em
> despite having access to them (I’ve only used a couple checked system
> drivers. ie. USB).
>
> You are correct on the IFS kit, it does cost a fair amount. I wish I
co=
uld
> get my hands on it for free…oh well.
>
> In summary, if you’re just starting out, don’t feel as though you need
large
> capital in order to start developing for windows.
>
> Chris
>
> P.S. This doesn’t just apply to device drivers. You can develop
applications
> for free using MS tools as well (you don’t need Visual
Studio…althoug=
h
IMO
> it is a great product and I use it).
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to %%email.unsub%%
>

----------------------------------------------------------------------

Subject: Registry for device driver? And Walter Oney?
From: Michael Wade
Date: Mon, 09 Dec 2002 17:17:40 -0800
X-Message-Number: 38

I apologize for asking such a basic question, but I really want to make
sure before I play around with the registry.

I thought that once upon a time the path to the registry key for the
driver
was passed into the driver. However, from reading around the net and
the
WDM DDK, I am confused. Where should I look to unconfuse myself? Is it

true that I should not use that path? I am resurrecting an NT 4 driver
and
hoping that getting it to work under Win2K won’t be impossible. We have

several parameters that need to be accessed by the driver and I would
think
that the registry would be the place for them. My device driver coding
is
really from NT4, but I know that we are going to go to WinXP so I would
like to do this “right” if possible. I was going to put the parameters
in
HKLM\System\CurrentControlSet\Services\MyDriver\Parameters(keys/values
here). Is that not correct anymore (if it ever was)? If not, where is
the
normal place to put device driver parameters?

Also, where is the normal/standard/whatever place to put device driver
data
that is too large to fit in the registry? We load hex files into our
card
and I don’t know if \Winnt\System32\drivers is the correct place or
not. If not, then where?

If anyone has any advice or knowledge I sure would appreciate you
passing
it on.

Also, I have Walter Oney’s book “Programming the Microsoft Windows
Driver
Model” from 1999. Is there a later release or another book that I
should
read? This one is fine, but I know that I am going to have to move this

driver to XP eventually and I don’t know what has changed. And I think
that Walter Oney’s book was published in 1999, before XP. Or are the
changes for XP so small that there really is no need?

Thanks very much,
Michael

----------------------------------------------------------------------

Subject: Property Page DLL in registry won’t change. When does one
change the
.inf class GUID?
From: Michael Wade
Date: Mon, 09 Dec 2002 17:21:04 -0800
X-Message-Number: 39

I see these heavy duty threads going on about interrupt priority and
filters and I feel like a little kid crying “Let me play! Let me
play! You never let me play!”

Be that as it may. I am trying to get a property page up and going and
I
thought that I did. But I can’t seem to get rid of my test dll for the
property page provider. I have a line in my .inf file that reads:
HKR,EnumPropPages32,“DevPropSheet.dll,DevicePropPageProvider”
It used to read:
HKR,EnumPropPages32,“TestDevPropSheet.dll,DevicePropPageProvider”

However, when I install it, my old “TestDevPropSheet.dll” seems to
always
get loaded. I have uninstalled the driver, deleted the corresponding
oem*.inf files and everything else I could think of. But it still wants
to
grab that test dll. I then looked in the registry for it, and it’s in
there under HKLM/SYSTEM/CurrentControlSet/(CLASSGUID). But I don’t know

why it’s not getting overwritten when I load the device driver again
using
the .inf file with the DevPropSheet.dll (without the Test). The GUID
corresponds to that in the [Version] section key = ClassGUID. Which
brings
up another question that is probably at the root. When should one
change
the Class GUID? And where does one find information about that GUID? I

tried the Win2k DDK, but if it’s there then I’m not finding it.

Thanks for any help,
Michael

----------------------------------------------------------------------

Subject: RE: Property Page DLL in registry won’t change. When does one
change the .inf class GUID?
From: “Doron Holan”
Date: Mon, 9 Dec 2002 17:29:38 -0800
X-Message-Number: 40

What is happening is that the class registry info is written only the
first time a device of that class is installed (ie the first time the OS
sees that new device class). Are you having these problems on a fresh
installed system where your test DLL has never been installed before?

Also, are you sure you want to have the property page for the entire
class? You can also install a property page on each individual device
(it ends up being in
HKLM/SYSTEM/CurrentControlSet/(CLASSGUID)/). The per instance
value is written everytime a device is installed (no matter the device
class).

D

This posting is provided “AS IS” with no warranties, and confers no
rights=20

-----Original Message-----
From: Michael Wade [mailto:xxxxx@pacbell.net]=20
Sent: Monday, December 09, 2002 5:21 PM
To: NT Developers Interest List
Subject: [ntdev] Property Page DLL in registry won’t change. When does
one change the .inf class GUID?

I see these heavy duty threads going on about interrupt priority and=20
filters and I feel like a little kid crying “Let me play! Let me=20
play! You never let me play!”

Be that as it may. I am trying to get a property page up and going and
I=20
thought that I did. But I can’t seem to get rid of my test dll for
the=20
property page provider. I have a line in my .inf file that reads:
HKR,EnumPropPages32,“DevPropSheet.dll,DevicePropPageProvider”
It used to read:
HKR,EnumPropPages32,“TestDevPropSheet.dll,DevicePropPageProvider”

However, when I install it, my old “TestDevPropSheet.dll” seems to
always=20
get loaded. I have uninstalled the driver, deleted the corresponding=20
oem*.inf files and everything else I could think of. But it still wants
to=20
grab that test dll. I then looked in the registry for it, and it’s
in=20
there under HKLM/SYSTEM/CurrentControlSet/(CLASSGUID). But I don’t know

why it’s not getting overwritten when I load the device driver again
using=20
the .inf file with the DevPropSheet.dll (without the Test). The GUID=20
corresponds to that in the [Version] section key =3D ClassGUID. Which
brings=20
up another question that is probably at the root. When should one
change=20
the Class GUID? And where does one find information about that GUID? I

tried the Win2k DDK, but if it’s there then I’m not finding it.

Thanks for any help,
Michael


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

----------------------------------------------------------------------

Subject: RE: Device Interrupt priority - Reviewing Jose Flores
From: “Jose Flores”
Date: Mon, 9 Dec 2002 20:48:21 -0500
X-Message-Number: 41

Yes interrupts associated with a higher IRQL than the current IRQL will
run end to end. At completion of the high IRQL isr, control is resumed
by
the lower IRQL. On all hals, everywhere.

However, on at least 1 common hal, an interrupt associated with an IRQL
lower than the current IRQL will (1) preempt and run for a little bit
(long enough for the OS stub to gain control), (2) be masked on the
controller (to prevent unwarrented preemption from happening again), (3)
be marked “pending” in memory, and (4) return control to the higher IRQL
(current) code block. Following the completion of the higher IRQL ISR,
control is resumed by the lower IRQL ISR, the interrupt “unpended”, and
be
unmasked in hardware & life goes on as normal.

In all hals, in all cases, the meat of a lower IRQL ISR is never run
before a higher IRQL ISR. Where meat is defined as the device driver’s
ISR passed to IoconnectInterrupt.

“Christiaan Ghijselinck” wrote in message
news:xxxxx@ntdev…
>
>
> Thanks for the reply Jake,
>
> You wrote :
>
> As for my understanding, may I conclude that higher level IRQ’s DO
> interrupt the running ISR and will run to the end, after which the
current
> interrupted ISR will continue ? Does this mean that the 8259 PIC’s IRQ
> priority handling is programmed/reprogrammed on the fly by the OS to
match
> the IRQL of the ISR’s in the system ?
>
>
>
>
>

----------------------------------------------------------------------

Subject: Re: Registry for device driver? And Walter Oney?
From: Phong Ho
Date: Mon, 9 Dec 2002 18:16:04 -0800 (PST)
X-Message-Number: 42

The second release of the Oney’s should be out on
December 9, 2002.
http://www.microsoft.com/mspress/books/6262.asp
I am wondering if the second release will cover
NDIS. Could the author let us know?

Thanks

— Michael Wade wrote:
> I apologize for asking such a basic question, but I
> really want to make
> sure before I play around with the registry.
>
> I thought that once upon a time the path to the
> registry key for the driver
> was passed into the driver. However, from reading
> around the net and the
> WDM DDK, I am confused. Where should I look to
> unconfuse myself? Is it
> true that I should not use that path? I am
> resurrecting an NT 4 driver and
> hoping that getting it to work under Win2K won’t be
> impossible. We have
> several parameters that need to be accessed by the
> driver and I would think
> that the registry would be the place for them. My
> device driver coding is
> really from NT4, but I know that we are going to go
> to WinXP so I would
> like to do this “right” if possible. I was going to
> put the parameters in
>
HKLM\System\CurrentControlSet\Services\MyDriver\Parameters(keys/values
>
> here). Is that not correct anymore (if it ever
> was)? If not, where is the
> normal place to put device driver parameters?
>
> Also, where is the normal/standard/whatever place to
> put device driver data
> that is too large to fit in the registry? We load
> hex files into our card
> and I don’t know if \Winnt\System32\drivers is the
> correct place or
> not. If not, then where?
>
> If anyone has any advice or knowledge I sure would
> appreciate you passing
> it on.
>
> Also, I have Walter Oney’s book “Programming the
> Microsoft Windows Driver
> Model” from 1999. Is there a later release or
> another book that I should
> read? This one is fine, but I know that I am going
> to have to move this
> driver to XP eventually and I don’t know what has
> changed. And I think
> that Walter Oney’s book was published in 1999,
> before XP. Or are the
> changes for XP so small that there really is no
> need?
>
> Thanks very much,
> Michael
>
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
%%email.unsub%%

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



END OF DIGEST


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

For me the reading appeared as statuating that high IRQL can be preempted by
low IRQL ISR.
Ill re-read it carefully. I might have been trapped into this beleif by the
writting style.

----- Original Message -----
From: “Jake Oshins”
To: “NT Developers Interest List”
Sent: Tuesday, December 10, 2002 8:13 PM
Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores

You’re right. I owe you an apology. A careful re-reading of your
article shows that you did understand the code.

I still think that the first half of your article makes little
distinction between taking an interrupt and calling a device driver’s
ISR. I believe that the difference between the two is meaningless to
most of the readers of this list. And it should be made very clear that
NT will never pre-empt a high-IRQL ISR with a low-IRQL ISR. It will
also never violate the locking semantics that are supported through the
concept of IRQL.

I don’t think that the fact that an interrupt is actually enabled or
disabled at the interrupt controller has much relevence in this context.
I don’t mean to say that you shouldn’t be interested in how things are
implemented. I just mean that you should be careful how you present
this, since I believe it clouded at least one reader’s overall
understanding.

- Jake

-----Original Message-----
Subject: RE: Device Interrupt priority - Reviewing Jose Flores
From: “Jose Flores”
Date: Mon, 9 Dec 2002 19:05:47 -0500
X-Message-Number: 36

Couple of things:

[1] Nowhere in that article does it recommend calling
IoConnectInterrupt()
w/ a made up IRQL. Nor does it advocate yanking & replacing hals out
from
underneath the installation.

The point of the article was (1) to give a peek at what goes on under
the
hood of IRQL manipulation and (2) to illustrate that raising IRQL does
not
always deny interrupts associated with lower priority IRQLs to fire. I
don’t think it’s a stretch do assume that most people take for granted
that if they raise to SYNCH that practically no interrupts will fire.
This is clearly not the case on UP systems. On such a hal, ALL
interrupts
will fire (initially), but the subsequent execution of NT’s interrupt
stub
will prevent the clients ISR from running until IRQL is lowered to an
acceptable level.

No doubt that this subtly hardly matters to anyone, except maybe a
handful
of people who are either doing seriously funky (most likely
non-production
quality) work, or are just morbidly curious.

[2] Nowhere in the article does it state that IRQL is meaningless on
uniprocessor systems. In fact it does describe what you call “Lazy
IRQL”.
From the article (edited for brevity):

“why do we use it (IRQL) at all on uniprocessor systems?..the NT kernel
performs explicit checks of the IRQL value at key points in it’s
execution…”

“…If the vector’s IRQL is less than or equal to the currently
executing
code’s IRQL, then everything is undone, the processor’s context is
restored, and control is returned to the interrupted code. … In cases
where the interrupt is dismissed, variables inside the PCR are used to
mark the particular interrupt vectors as having had an interrupt fire
that
was not completely serviced. … dismissing the interrupt is usually
followed with actually masking the particular interrupt in hardware to
prevent further execution of the ISR until the pending interrupt can be
serviced completely.”

“Each time IRQL is dropped, a check is performed to see if there are any
‘pending’ interrupts. If so, then a software interrupt is issued (after
the IRQL is dropped) corresponding to the vector to which the hardware
interrupt is mapped. For example, if the clock interrupt is mapped to
vector 0x30 with an IRQL of 0x1C, then if the current IRQL is dropping
from 0x1F to 0x2, then … The ISR executes as normal, and the
interrupt is
now completely serviced. The pending bit is cleared, and the interrupt
is
unmasked.”

Granted the article wasn’t privy to more colorful insider descriptions
such as Lazy and Strict IRQL, but the end description is essentially the
same. Likewise, what the article calls an interrupt stub, you call a
preamble. Tomato, tomato.

Maybe the unfinished article was poorly written to have anyone to
conclude
that the article suggests the above. Or maybe it just wasn’t read in
the
right frame of mind. Either way, I’d be interested in hearing
criticisms
privately from someone with your inside knowledge.

“Jake Oshins” wrote in message
news:xxxxx@ntdev…

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
itself.

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
misunderstandings.

Jake Oshins
NT Kernel Team
Microsoft

This posting is provided “AS IS” with no warranties, and confers no
rights.

-----Original Message-----
Subject: Device Interrupt priority & Extreme ISR Priority : new thread
From: “Christiaan Ghijselinck”
Date: Sun, 8 Dec 2002 09:33:59 -0500
X-Message-Number: 2

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
the
multiprocessor version ( halmps.dll ).

----------------------------------------------------------------------

Subject: Re: Writng and Debuging Drivers in C++
From: “David J. Craig”
Date: Mon, 9 Dec 2002 19:02:25 -0500
X-Message-Number: 37

I think MSDN is required for someone in the development group to have
available. You can get the DDKs for “free” if you have one. I have
also
found that keeping the old DDKs, SDKs, and operating systems to be
necess=
ary
because most of the world isn’t switching as quickly as Microsoft would
like. There is the archive pack with some of the old stuff too. I have
found that some documentation disappears if you don’t have access to the
older versions. Also there is one hardware “requirement” that OSR
advise=
s
and that is a 8x SMP system. Some deadlocks and other SMP issues may
not
show up quickly on a single CPU or a dual processor. I remember
releasin=
g
one driver that had the no-SMP flag set. We didn’t have a SMP system to
test and the risk to our partners was deemed too high. I have been at a
company where only one or two of the systems had DVDs. Every other
syste=
m
had CD-ROMs only. I prefer the paychecks get paid instead of having all
=
the
toys I want, but I still want the toys.

I think that using the checked builds of the HAL and Kernel is required
t=
o
drivers stable. I don’t think that you need the entire checked OS for
drivers, but you may want it for some applications.

----- Original Message -----
From: “Chris Dor=E9”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Monday, December 09, 2002 5:34 PM
Subject: [ntdev] Re: Writng and Debuging Drivers in C++

> >
> > It is expensive and Microsoft has not done much itself to reduce
cost=
s.
> > Windbg is “free”, but you still have to download it. Just printing
t=
he
> user
> > guide will chew up most of a ream of paper. MSDN is absurdly
expensi=
ve
> and
> > appears designed to limit the ability to develop to those who have
de=
ep
> > pockets. MSDN Universal costs more than the two computers you need
t=
o
> write
> > drivers. Add in the IFS Kits and you need $10,000 just to start in
t=
he
> > first year. Remember when many shareware developers could write
usef=
ul
> > utilities, TSRs, and drivers for MS-DOS with little or no expense
exc=
ept
> the
> > hardware. The costs seem to have shifted from hardware to software.
=
I
> just
> > read that Microsoft has said that its costs for their operating
syste=
ms
is
> > only $0.15 or $0.16 per dollar charged. Nice margins!
> >
>
> You do not, by any means, need an MSDN subscription to develop device
> drivers. If you have access to the internet then you’re completely
set.
The
> DDK is practically free (just pay for the shipping), and the entire
MSD=
N
> library is available for free on Microsoft’s website. The DDK comes
wit=
h a
> compiler and everything you need to build a driver…in fact you don’t
> really even need access to the internet (of course access to the
extr=
a
> information is quite a help).
>
> Now there are some useful things lacking from not having a MSDN
> subscription, like checked OS builds, but I have actually never used
th=
em
> despite having access to them (I’ve only used a couple checked system
> drivers. ie. USB).
>
> You are correct on the IFS kit, it does cost a fair amount. I wish I
co=
uld
> get my hands on it for free…oh well.
>
> In summary, if you’re just starting out, don’t feel as though you need
large
> capital in order to start developing for windows.
>
> Chris
>
> P.S. This doesn’t just apply to device drivers. You can develop
applications
> for free using MS tools as well (you don’t need Visual
Studio…althoug=
h
IMO
> it is a great product and I use it).
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to %%email.unsub%%
>

----------------------------------------------------------------------

Subject: Registry for device driver? And Walter Oney?
From: Michael Wade
Date: Mon, 09 Dec 2002 17:17:40 -0800
X-Message-Number: 38

I apologize for asking such a basic question, but I really want to make
sure before I play around with the registry.

I thought that once upon a time the path to the registry key for the
driver
was passed into the driver. However, from reading around the net and
the
WDM DDK, I am confused. Where should I look to unconfuse myself? Is it

true that I should not use that path? I am resurrecting an NT 4 driver
and
hoping that getting it to work under Win2K won’t be impossible. We have

several parameters that need to be accessed by the driver and I would
think
that the registry would be the place for them. My device driver coding
is
really from NT4, but I know that we are going to go to WinXP so I would
like to do this “right” if possible. I was going to put the parameters
in
HKLM\System\CurrentControlSet\Services\MyDriver\Parameters(keys/values
here). Is that not correct anymore (if it ever was)? If not, where is
the
normal place to put device driver parameters?

Also, where is the normal/standard/whatever place to put device driver
data
that is too large to fit in the registry? We load hex files into our
card
and I don’t know if \Winnt\System32\drivers is the correct place or
not. If not, then where?

If anyone has any advice or knowledge I sure would appreciate you
passing
it on.

Also, I have Walter Oney’s book “Programming the Microsoft Windows
Driver
Model” from 1999. Is there a later release or another book that I
should
read? This one is fine, but I know that I am going to have to move this

driver to XP eventually and I don’t know what has changed. And I think
that Walter Oney’s book was published in 1999, before XP. Or are the
changes for XP so small that there really is no need?

Thanks very much,
Michael

----------------------------------------------------------------------

Subject: Property Page DLL in registry won’t change. When does one
change the
.inf class GUID?
From: Michael Wade
Date: Mon, 09 Dec 2002 17:21:04 -0800
X-Message-Number: 39

I see these heavy duty threads going on about interrupt priority and
filters and I feel like a little kid crying “Let me play! Let me
play! You never let me play!”

Be that as it may. I am trying to get a property page up and going and
I
thought that I did. But I can’t seem to get rid of my test dll for the
property page provider. I have a line in my .inf file that reads:
HKR,EnumPropPages32,“DevPropSheet.dll,DevicePropPageProvider”
It used to read:
HKR,EnumPropPages32,“TestDevPropSheet.dll,DevicePropPageProvider”

However, when I install it, my old “TestDevPropSheet.dll” seems to
always
get loaded. I have uninstalled the driver, deleted the corresponding
oem*.inf files and everything else I could think of. But it still wants
to
grab that test dll. I then looked in the registry for it, and it’s in
there under HKLM/SYSTEM/CurrentControlSet/(CLASSGUID). But I don’t know

why it’s not getting overwritten when I load the device driver again
using
the .inf file with the DevPropSheet.dll (without the Test). The GUID
corresponds to that in the [Version] section key = ClassGUID. Which
brings
up another question that is probably at the root. When should one
change
the Class GUID? And where does one find information about that GUID? I

tried the Win2k DDK, but if it’s there then I’m not finding it.

Thanks for any help,
Michael

----------------------------------------------------------------------

Subject: RE: Property Page DLL in registry won’t change. When does one
change the .inf class GUID?
From: “Doron Holan”
Date: Mon, 9 Dec 2002 17:29:38 -0800
X-Message-Number: 40

What is happening is that the class registry info is written only the
first time a device of that class is installed (ie the first time the OS
sees that new device class). Are you having these problems on a fresh
installed system where your test DLL has never been installed before?

Also, are you sure you want to have the property page for the entire
class? You can also install a property page on each individual device
(it ends up being in
HKLM/SYSTEM/CurrentControlSet/(CLASSGUID)/). The per instance
value is written everytime a device is installed (no matter the device
class).

D

This posting is provided “AS IS” with no warranties, and confers no
rights=20

-----Original Message-----
From: Michael Wade [mailto:xxxxx@pacbell.net]=20
Sent: Monday, December 09, 2002 5:21 PM
To: NT Developers Interest List
Subject: [ntdev] Property Page DLL in registry won’t change. When does
one change the .inf class GUID?

I see these heavy duty threads going on about interrupt priority and=20
filters and I feel like a little kid crying “Let me play! Let me=20
play! You never let me play!”

Be that as it may. I am trying to get a property page up and going and
I=20
thought that I did. But I can’t seem to get rid of my test dll for
the=20
property page provider. I have a line in my .inf file that reads:
HKR,EnumPropPages32,“DevPropSheet.dll,DevicePropPageProvider”
It used to read:
HKR,EnumPropPages32,“TestDevPropSheet.dll,DevicePropPageProvider”

However, when I install it, my old “TestDevPropSheet.dll” seems to
always=20
get loaded. I have uninstalled the driver, deleted the corresponding=20
oem*.inf files and everything else I could think of. But it still wants
to=20
grab that test dll. I then looked in the registry for it, and it’s
in=20
there under HKLM/SYSTEM/CurrentControlSet/(CLASSGUID). But I don’t know

why it’s not getting overwritten when I load the device driver again
using=20
the .inf file with the DevPropSheet.dll (without the Test). The GUID=20
corresponds to that in the [Version] section key =3D ClassGUID. Which
brings=20
up another question that is probably at the root. When should one
change=20
the Class GUID? And where does one find information about that GUID? I

tried the Win2k DDK, but if it’s there then I’m not finding it.

Thanks for any help,
Michael


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

----------------------------------------------------------------------

Subject: RE: Device Interrupt priority - Reviewing Jose Flores
From: “Jose Flores”
Date: Mon, 9 Dec 2002 20:48:21 -0500
X-Message-Number: 41

Yes interrupts associated with a higher IRQL than the current IRQL will
run end to end. At completion of the high IRQL isr, control is resumed
by
the lower IRQL. On all hals, everywhere.

However, on at least 1 common hal, an interrupt associated with an IRQL
lower than the current IRQL will (1) preempt and run for a little bit
(long enough for the OS stub to gain control), (2) be masked on the
controller (to prevent unwarrented preemption from happening again), (3)
be marked “pending” in memory, and (4) return control to the higher IRQL
(current) code block. Following the completion of the higher IRQL ISR,
control is resumed by the lower IRQL ISR, the interrupt “unpended”, and
be
unmasked in hardware & life goes on as normal.

In all hals, in all cases, the meat of a lower IRQL ISR is never run
before a higher IRQL ISR. Where meat is defined as the device driver’s
ISR passed to IoconnectInterrupt.

“Christiaan Ghijselinck” wrote in message
news:xxxxx@ntdev…
>
>
> Thanks for the reply Jake,
>
> You wrote :
>
> As for my understanding, may I conclude that higher level IRQ’s DO
> interrupt the running ISR and will run to the end, after which the
current
> interrupted ISR will continue ? Does this mean that the 8259 PIC’s IRQ
> priority handling is programmed/reprogrammed on the fly by the OS to
match
> the IRQL of the ISR’s in the system ?
>
>
>
>
>

----------------------------------------------------------------------

Subject: Re: Registry for device driver? And Walter Oney?
From: Phong Ho
Date: Mon, 9 Dec 2002 18:16:04 -0800 (PST)
X-Message-Number: 42

The second release of the Oney’s should be out on
December 9, 2002.
http://www.microsoft.com/mspress/books/6262.asp
I am wondering if the second release will cover
NDIS. Could the author let us know?

Thanks

— Michael Wade wrote:
> I apologize for asking such a basic question, but I
> really want to make
> sure before I play around with the registry.
>
> I thought that once upon a time the path to the
> registry key for the driver
> was passed into the driver. However, from reading
> around the net and the
> WDM DDK, I am confused. Where should I look to
> unconfuse myself? Is it
> true that I should not use that path? I am
> resurrecting an NT 4 driver and
> hoping that getting it to work under Win2K won’t be
> impossible. We have
> several parameters that need to be accessed by the
> driver and I would think
> that the registry would be the place for them. My
> device driver coding is
> really from NT4, but I know that we are going to go
> to WinXP so I would
> like to do this “right” if possible. I was going to
> put the parameters in
>
HKLM\System\CurrentControlSet\Services\MyDriver\Parameters(keys/values
>
> here). Is that not correct anymore (if it ever
> was)? If not, where is the
> normal place to put device driver parameters?
>
> Also, where is the normal/standard/whatever place to
> put device driver data
> that is too large to fit in the registry? We load
> hex files into our card
> and I don’t know if \Winnt\System32\drivers is the
> correct place or
> not. If not, then where?
>
> If anyone has any advice or knowledge I sure would
> appreciate you passing
> it on.
>
> Also, I have Walter Oney’s book “Programming the
> Microsoft Windows Driver
> Model” from 1999. Is there a later release or
> another book that I should
> read? This one is fine, but I know that I am going
> to have to move this
> driver to XP eventually and I don’t know what has
> changed. And I think
> that Walter Oney’s book was published in 1999,
> before XP. Or are the
> changes for XP so small that there really is no
> need?
>
> Thanks very much,
> Michael
>
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
%%email.unsub%%

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com



END OF DIGEST


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%

>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.

Sorry, but why Lazy IRQL was not used on UP ACPI HAL (HALACPI)?

Max

> Somewhere I have read that all DPC’s for a particular processor
within the

system are FIFO queued
to run at the same IRQL. This would mean that when a high priority
ISR
queues a DPC, this DPC will
only come to run when all other DPC’s, even those queued by less
priority
ISR’s, have finished.
Is this correct ?

Yes.

Max

> issues an STI. This leaves a small window within which an interrupt
could

theoretically be missed

It will not. It will be put on hold on PIC/APIC.

Max

Correct, but it can hold only ONE ! See my previous answer on this theme

----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Wednesday, December 11, 2002 10:20 AM
Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores

> > issues an STI. This leaves a small window within which an interrupt
> could
> > theoretically be missed
>
> It will not. It will be put on hold on PIC/APIC.
>
> Max
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@Compaqnet.be
> To unsubscribe send a blank email to %%email.unsub%%
>

Well thanks. This is something for the “MS Driver Survey”.
I need a DPC queue per available interrupt IRQL, handled
accordingly.

----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Wednesday, December 11, 2002 10:17 AM
Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores

> > Somewhere I have read that all DPC’s for a particular processor
> within the
> > system are FIFO queued
> > to run at the same IRQL. This would mean that when a high priority
> ISR
> > queues a DPC, this DPC will
> > only come to run when all other DPC’s, even those queued by less
> priority
> > ISR’s, have finished.
> > Is this correct ?
>
> Yes.
>
> Max
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@Compaqnet.be
> To unsubscribe send a blank email to %%email.unsub%%
>

Unless the APIC has the ability to queue interrupts, that will be of limited
usefulness. The last machine I worked with that could queue interrupts by
hardware was the Sperry Univac 418III, way back in the seventies and
eighties. Anybody know any other systems that do it ?

Alberto.

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, December 11, 2002 4:20 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores

issues an STI. This leaves a small window within which an interrupt
could
theoretically be missed

It will not. It will be put on hold on PIC/APIC.

Max


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

Hmm, aren’t PCI IRQs level triggered ?
With level triggered IRQ you never loose one.
But the term ‘loose’ depends on how you define it. Your hardware may
have some max. latency requirements that make you loose an event.
Norbert.

“If you have tried something and failed, you are vastly better off
than if you had tried nothing and succeeded.”
---- snip ----

Unless the APIC has the ability to queue interrupts, that will be of limited
usefulness. The last machine I worked with that could queue interrupts by
hardware was the Sperry Univac 418III, way back in the seventies and
eighties. Anybody know any other systems that do it ?

---- snip ----

The PCI bus will hold the IRQ signal till the driver’s ISR will reset
it. With any PIC, be it 8259 or APIC.

Max

----- Original Message -----
From: “Moreira, Alberto”
To: “NT Developers Interest List”
Sent: Wednesday, December 11, 2002 6:13 PM
Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores

> Unless the APIC has the ability to queue interrupts, that will be of
limited
> usefulness. The last machine I worked with that could queue
interrupts by
> hardware was the Sperry Univac 418III, way back in the seventies and
> eighties. Anybody know any other systems that do it ?
>
> Alberto.
>
>
> -----Original Message-----
> From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> Sent: Wednesday, December 11, 2002 4:20 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose
Flores
>
>
> > issues an STI. This leaves a small window within which an
interrupt
> could
> > theoretically be missed
>
> It will not. It will be put on hold on PIC/APIC.
>
> Max
>
>
>
> —
> You are currently subscribed to ntdev as:
xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> The contents of this e-mail are intended for the named addressee
only. It
> contains information that may be confidential. Unless you are the
named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>

Who will rise to the next challenge :

"Four PCI cards fire quasi at the same moment ( assume 100 ns time
difference ) an interrupt. Card1 , card2 and card3 have different IRQ’s ,
card4 shares the same IRQ with card3.

I would like to see a detailled flow of all handschaking actions between the
Cards <–> [PCI bus <– >] PIC/APIC <–> CPU with bus <–> OS/ISR’s in
both the “Lazy” and the “Strict Model”. The flow ends when the last ( fourth )
IRQ has been completely serviced.

Such a description would have an incredible value .

----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Wednesday, December 11, 2002 7:20 PM
Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores

> The PCI bus will hold the IRQ signal till the driver’s ISR will reset
> it. With any PIC, be it 8259 or APIC.
>
> Max
>
> ----- Original Message -----
> From: “Moreira, Alberto”
> To: “NT Developers Interest List”
> Sent: Wednesday, December 11, 2002 6:13 PM
> Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores
>
>
> > Unless the APIC has the ability to queue interrupts, that will be of
> limited
> > usefulness. The last machine I worked with that could queue
> interrupts by
> > hardware was the Sperry Univac 418III, way back in the seventies and
> > eighties. Anybody know any other systems that do it ?
> >
> > Alberto.
> >
> >
> > -----Original Message-----
> > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> > Sent: Wednesday, December 11, 2002 4:20 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose
> Flores
> >
> >
> > > issues an STI. This leaves a small window within which an
> interrupt
> > could
> > > theoretically be missed
> >
> > It will not. It will be put on hold on PIC/APIC.
> >
> > Max
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> xxxxx@compuware.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee
> only. It
> > contains information that may be confidential. Unless you are the
> named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@Compaqnet.be
> To unsubscribe send a blank email to %%email.unsub%%
>

I thought the APIC in fact had the ability to queue one or perhaps two interrupts per source
if no target were ready to service the interrupt.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

The PCI bus will hold the IRQ signal till the driver’s ISR will reset
it. With any PIC, be it 8259 or APIC.

Max

----- Original Message -----
From: “Moreira, Alberto”
> To: “NT Developers Interest List”
> Sent: Wednesday, December 11, 2002 6:13 PM
> Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores
>
>
> > Unless the APIC has the ability to queue interrupts, that will be of
> limited
> > usefulness. The last machine I worked with that could queue
> interrupts by
> > hardware was the Sperry Univac 418III, way back in the seventies and
> > eighties. Anybody know any other systems that do it ?
> >
> > Alberto.
> >
> >
> > -----Original Message-----
> > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> > Sent: Wednesday, December 11, 2002 4:20 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose
> Flores
> >
> >
> > > issues an STI. This leaves a small window within which an
> interrupt
> > could
> > > theoretically be missed
> >
> > It will not. It will be put on hold on PIC/APIC.
> >
> > Max
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> xxxxx@compuware.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee
> only. It
> > contains information that may be confidential. Unless you are the
> named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to %%email.unsub%%

>"Four PCI cards fire quasi at the same moment ( assume 100 ns time

difference ) an interrupt. Card1 , card2 and card3 have different
IRQ’s ,
card4 shares the same IRQ with card3.
I would like to see a detailled flow of all handschaking actions
between the

I will omit cards1, 2, 3 and describe only cards 3 and 4.

  • card 3 starts to pull INTA# down. Note that the line is
    open-collector.
  • card 4 starts to pull INTA# down.
  • this pull-down causes the PIC to interrupt the CPU.
  • the PIC’s mask is raised to this IRQ.
  • the CPU, after possibly executing STI, starts to execute a vector
  • the NT kernel enumerates all drivers on these vectors
  • it calls ISR for card 3
  • the ISR writes something to card 3, which stops it from pulling
    INTA# down.
  • nevertheless, INTA# is still pulled down by card 4
  • card 3 ISR done, the NT kernel calls card 4’s ISR
  • the ISR writes something to card 4, which stops it from pulling
    INTA# down.
  • nobody more pulls INTA# down. It is pulled up by a resistor.
  • PIC returns to passive (no interrupt pending) mode
  • the NT kernel returns from the last ISR and executes IRET.

Max

Sorry, what is queuing an interrupt?
The PCI card just holds INTA# down till the driver’s ISR will reset it
from this state. So, no more interrupts from the same PCI card can
occur during this :slight_smile:

Max

----- Original Message -----
From: “Mark Roddy”
To: “NT Developers Interest List”
Sent: Wednesday, December 11, 2002 11:46 PM
Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores

> I thought the APIC in fact had the ability to queue one or perhaps
two interrupts per source
> if no target were ready to service the interrupt.
>
> ===========================
> Mark Roddy
> Consultant, Microsoft DDK MVP
> Hollis Technology Solutions
> xxxxx@hollistech.com
> www.hollistech.com
> 603-321-1032
>
>
> > The PCI bus will hold the IRQ signal till the driver’s ISR will
reset
> > it. With any PIC, be it 8259 or APIC.
> >
> > Max
> >
> > ----- Original Message -----
> > From: “Moreira, Alberto”
> > To: “NT Developers Interest List”
> > Sent: Wednesday, December 11, 2002 6:13 PM
> > Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose
Flores
> >
> >
> > > Unless the APIC has the ability to queue interrupts, that will
be of
> > limited
> > > usefulness. The last machine I worked with that could queue
> > interrupts by
> > > hardware was the Sperry Univac 418III, way back in the seventies
and
> > > eighties. Anybody know any other systems that do it ?
> > >
> > > Alberto.
> > >
> > >
> > > -----Original Message-----
> > > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> > > Sent: Wednesday, December 11, 2002 4:20 AM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose
> > Flores
> > >
> > >
> > > > issues an STI. This leaves a small window within which an
> > interrupt
> > > could
> > > > theoretically be missed
> > >
> > > It will not. It will be put on hold on PIC/APIC.
> > >
> > > Max
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
> > xxxxx@compuware.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> > >
> > >
> > > The contents of this e-mail are intended for the named addressee
> > only. It
> > > contains information that may be confidential. Unless you are
the
> > named
> > > addressee or an authorized designee, you may not copy or use it,
or
> > disclose
> > > it to anyone else. If you received it in error please notify us
> > immediately
> > > and then destroy it.
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hollistech.com
> > To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>

> The PCI card just holds INTA# down till the driver’s ISR will reset it

How ? I thought the hardware signal INTA# is reset by the PIC. There
are no software instructions for that. The OS acknowledges the PIC
in different ways, see “Lazy” vs. “Strict”

Sorry Max, this is too popular. I like to see the cycle loop when the PIC
puts the “int”
instruction on the bus, when in the mean time other cards take the INTA#
down. I also
like to know the reaction of the PIC when priorities are changed and /or
interrupts
are masked off within the “Lazy” and “Strict” model, also when the PIC
cannot
push a new “int” and vector because of a cleared interrupt flag, even then
when it
has already been ACK’d by the processor, etc…
Note : everything I state here is more or less an assumption until I get a
non-popular
description

Christiaan

----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Wednesday, December 11, 2002 10:52 PM
Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores

> >"Four PCI cards fire quasi at the same moment ( assume 100 ns time
> >difference ) an interrupt. Card1 , card2 and card3 have different
> IRQ’s ,
> >card4 shares the same IRQ with card3.
> >I would like to see a detailled flow of all handschaking actions
> between the
>
> I will omit cards1, 2, 3 and describe only cards 3 and 4.
>
> - card 3 starts to pull INTA# down. Note that the line is
> open-collector.
> - card 4 starts to pull INTA# down.
> - this pull-down causes the PIC to interrupt the CPU.
> - the PIC’s mask is raised to this IRQ.
> - the CPU, after possibly executing STI, starts to execute a vector
> - the NT kernel enumerates all drivers on these vectors
> - it calls ISR for card 3
> - the ISR writes something to card 3, which stops it from pulling
> INTA# down.
> - nevertheless, INTA# is still pulled down by card 4
> - card 3 ISR done, the NT kernel calls card 4’s ISR
> - the ISR writes something to card 4, which stops it from pulling
> INTA# down.
> - nobody more pulls INTA# down. It is pulled up by a resistor.
> - PIC returns to passive (no interrupt pending) mode
> - the NT kernel returns from the last ISR and executes IRET.
>
> Max
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@Compaqnet.be
> To unsubscribe send a blank email to %%email.unsub%%
>

PCI controllers are generally designed so that their interrupt signal output is “asserted” 'til some systems software (like a device driver, usually code in a first-level or second-level interrupt handler) performs a well-defined operation to clear the condition which caused the controller to “assert” the interrupt to start with.

So, I think the answer to this question is “by definition of a PCI 2.1 (and lesser version) controller level-sensitive interrupt mechanism”.

When PCI 2.2-2.3 becomes ubiquitous, we’ll be discussing “how does Message Signaled Interrupts” work.

Cheers

-----Original Message-----
From: Christiaan Ghijselinck [mailto:xxxxx@CompaqNet.be]
Sent: Wednesday, December 11, 2002 4:12 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Device Interrupt priority - Reviewing Jose Flores

The PCI card just holds INTA# down till the driver’s ISR will reset it

How ? I thought the hardware signal INTA# is reset by the PIC. There
are no software instructions for that. The OS acknowledges the PIC
in different ways, see “Lazy” vs. “Strict”

> Note : everything I state here is more or less an assumption until I
get a

non-popular
description

You can find it on Intel’s site - for both 8259 and APIC.

Max

> > The PCI card just holds INTA# down till the driver’s ISR will
reset it

How ? I thought the hardware signal INTA# is reset by the PIC.

No.
The only way of resetting it is the card-dependent one (writing to
status or “IRQ disable” register), and only the card’s driver can (and
must) do this.

are no software instructions for that. The OS acknowledges the PIC

The only “acknowledgement” for PCI IRQs is the card-dependent one.

Max