ISR routine returns FALSE

NTDEV
1

Hi All,

I’m porting a PCI device Driver from WDM to KMDF.
The new KMDF driver can be worked well in Vista,but in XP it has problem.
It caused system crashed when run app for a period of time in XP.

I doubt ISR rountine caused it so I traced it in driver.
In ISR routine,I first judge whether the interrupt is generated by our device.
If it is,do our work,request DPC,then return TRUE.If not,return FALSE.

ISR routine returns FALSE sometimes in XP,but in Vista it never return FALSE.
[the same device the same driver the same app]
And our old WDM driver never return FALSE also.

I do not know why there be such a problem.
The difference of ISR routine performance caused system crashed in XP?
[If in app,I do not use interrupt the driver supplied,XP system can be stable.]

Someone encountered a similar problem with me?

Any help is appreciated.Thanks.

Best Regards
Zhou ChengJun

2

An ISR returns false if the ISR is invoked when the device is not requesting
an interrupt. In XP your ISR was sharing the interrupt with another device,
so sometimes the ISR was invoked when it was the other device that was the
interrupt source. Vista appears to have done a better job at resource
allocation and your device does not have a shared interrupt.

On Mon, Mar 17, 2008 at 8:29 AM, wrote:

> Hi All,
>
> I’m porting a PCI device Driver from WDM to KMDF.
> The new KMDF driver can be worked well in Vista,but in XP it has problem.
> It caused system crashed when run app for a period of time in XP.
>
> I doubt ISR rountine caused it so I traced it in driver.
> In ISR routine,I first judge whether the interrupt is generated by our
> device.
> If it is,do our work,request DPC,then return TRUE.If not,return FALSE.
>
> ISR routine returns FALSE sometimes in XP,but in Vista it never return
> FALSE.
> [the same device the same driver the same app]
> And our old WDM driver never return FALSE also.
>
> I do not know why there be such a problem.
> The difference of ISR routine performance caused system crashed in XP?
> [If in app,I do not use interrupt the driver supplied,XP system can be
> stable.]
>
> Someone encountered a similar problem with me?
>
> Any help is appreciated.Thanks.
>
> Best Regards
> Zhou ChengJun
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Mark Roddy

3

Well,how can avoid it?[The difference of ISR routine performance caused system crashed in XP] “Don’t share the interrupt with another device” can do?How can realize this?
Thanks.

4

You can’t avoid it. You have some bug you need to fix. The first step is to
analyze the crash and understand why your driver is crashing. “It is
crashing because it is sharing interrupts” is not a root cause.

On Mon, Mar 17, 2008 at 9:24 PM, wrote:

> Well,how can avoid it?[The difference of ISR routine performance caused
> system crashed in XP] “Don’t share the interrupt with another device” can
> do?How can realize this?
> Thanks.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Mark Roddy

5

> Vista appears to have done a better job at resource allocation and your device does

not have a shared interrupt.

IRQ sharing has nothing to do with the OS - the OS gets all info about IRQs from BIOS tables, and it has to respect this info when dealing with interrupts . If BIOS says that IRQ X is shared by PCI devices A, B and C (I assume interrupt is asserted via pin, rather MSI), then the OS has no choice but to allocate and map resources the way BIOS says. Therefore, as long as target devices are not MSI-capable, it does not matter whether the target OS is XP or Vista. The only reason why there is less interrupt sharing under Vista is because it supports MSI, so that it can program MSI-capable device to raise interrupts via Message Address and Message data registers, rather than via pin. Therefore, as long as our imaginary devices A, B and C are MSI-capable, they have a chance to get dedicated vector under Vista but have to share IRQ under XP…

Anton Bassov

6

wrote in message news:xxxxx@ntdev…
>> Vista appears to have done a better job at resource allocation and your
>> device does
>> not have a shared interrupt.
>
> IRQ sharing has nothing to do with the OS - the OS gets all info about
> IRQs from BIOS tables, and it has to respect this info when dealing with
> interrupts . If BIOS says that IRQ X is shared by PCI devices A, B and C
> (I assume interrupt is asserted via pin, rather MSI), then the OS has no
> choice but to allocate and map resources the way BIOS says. Therefore, as
> long as target devices are not MSI-capable, it does not matter whether
> the target OS is XP or Vista. The only reason why there is less interrupt
> sharing under Vista is because it supports MSI, so that it can program
> MSI-capable device to raise interrupts via Message Address and Message
> data registers, rather than via pin. Therefore, as long as our imaginary
> devices A, B and C are MSI-capable, they have a chance to get dedicated
> vector under Vista but have to share IRQ under XP…
>

Sorry Anton this is incorrect. Windows over the years has ignored the BIOS
this is why there is /PCILOCK among other things.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

7

>BIOS tables, and it has to respect this info when dealing with interrupts .
If BIOS

says that IRQ X is shared by PCI devices A, B and C

This was so only in the days of Pentium-166 and VX chipset, where the PCI INT#
lines were hard-wired to PIC inputs.

ACPI BIOSes can reroute this mapping, especially if the IO APIC is present
which has 255 IRQs and not the good old PC/AT 16 ones.

ACPI/APIC machine is the usual machine since the days of hyperthreaded
Prescotts, if not Northwoods.

So, interrupt flexibility predates MSIs a lot.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

8

> Sorry Anton this is incorrect. Windows over the years has ignored the BIOS

this is why there is /PCILOCK among other things.

NT4 always obeyed the BIOS PCI IRQ settings, but NT4 was pre-ACPI OS.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

9

Not so, I used /PCILOCK on NT4 for a failover system because otherwise NT
would take two identical systems and set the IRQ’s and resources diferent!

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> Sorry Anton this is incorrect. Windows over the years has ignored the
>> BIOS
>> this is why there is /PCILOCK among other things.
>
> NT4 always obeyed the BIOS PCI IRQ settings, but NT4 was pre-ACPI OS.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

10

So in that case Vista would be doing a better job at resource
allocation, right?

Perhaps I am missing your point. By the way, it is rather unlikely that
there are any MSI capable devices on the OP’s system with MSI enabled
drivers, so there has to be some other explanation for why on the same
platform the XP driver has shared interrupts and the Vista driver does
not. One possible explanation is that you are simply wrong about bios
hardwiring.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Tuesday, March 18, 2008 9:41 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ISR routine returns FALSE

Vista appears to have done a better job at resource allocation and
your device does
not have a shared interrupt.

IRQ sharing has nothing to do with the OS - the OS gets all info about
IRQs from BIOS tables, and it has to respect this info when dealing
with interrupts . If BIOS says that IRQ X is shared by PCI devices A, B
and C (I assume interrupt is asserted via pin, rather MSI), then the OS
has no choice but to allocate and map resources the way BIOS says.
Therefore, as long as target devices are not MSI-capable, it does not
matter whether the target OS is XP or Vista. The only reason why there
is less interrupt sharing under Vista is because it supports MSI, so
that it can program MSI-capable device to raise interrupts via Message
Address and Message data registers, rather than via pin. Therefore, as
long as our imaginary devices A, B and C are MSI-capable, they have a
chance to get dedicated vector under Vista but have to share IRQ under
XP…

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

11

Maxim,

This was so only in the days of Pentium-166 and VX chipset, where the PCI INT# lines were
hard-wired to PIC inputs. ACPI BIOSes can reroute this mapping, especially if the
IO APIC is present which has 255 IRQs and not the good old PC/AT 16 ones.

First of all, single IO APIC normally has just 24 pins and not 255 as you say (although these days the same machine may have multiple IO APICs) -apparently, you just have confused IOAPIC with IDT.

Second, when it comes to APIC, the term “IRQ” is a bit misleading - it refers to IOAPIC pins, rather than PIC inputs. This is why you see such terms as “IRQ 22”, “IRQ 27” ,etc, although only 16 PIC inputs are available - the former means pin 22 of IOAPIC 1 , and the second one means pin 3 of IOAPIC 2.

Third, there is no need for ACPI to re-route IRQ to IOAPIC pins - non-ACPI MP BIOS can do it without a slightest problem (check MP Specifications for more info). Basically, there are 2 types of Interrupt Assignment Entries of MP Configuration Table, i.e. for PCI and ISA devices. In latter case, interrupt assignment entry just maps ISA IRQ to IOAPIC pin (normally sequentially, but at least one exception is always made).

In former case, interrupt assignment entry has the following format: “PCI bus A - device X - interrupts pin N - IOAPIC pin XXX”, where XXX holds both IOAPIC and pin number the way I have explained above. Therefore, in order to map PCI device to IRQ the system has to find an interrupt assignment entry in MP Configuration Table that matches bus, device, and InterruptPin-1 of the target device (InterruptPin field that is available from Configuration Space is always valid, although InterruptLine one is not when APIC is around - it applies only to PIC).

Every PCI devices has its own corresponding interrupt assignment entry in MP Configuration Table.Therefore, if the OS sees that the same IOAPIC pin number is specified in multiple interrupt assignment entries and devices in question are not MSI-capable, they have no option, other that sharing IRQ (i.e. IOAPIC interrupt pin), and once every IOAPIC pin may be mapped only to one interrupt vector, they have to share vector as well. If they are MSI-capable, then it can program them to raise interrupts via Message Address and Message data registers, rather than via pin, so that they can get assigned dedicated vectors…

Anton Bassov

12

Don,

Windows over the years has ignored the BIOS this is why there is /PCILOCK among other things.

It does not ignore BIOS - what it actually ignores as just those parameters that would apply if it ran in PIC mode. This is why ‘InterruptLine’ that is available from PCI configuration space is invalid in APIC mode - it applies only to PIC mode. However, mapping of PCI device interrupt pins to IOAPIC pins is still obtained from BIOS - please read my previous post.

Anton Bassov

13

Interesting.

If you set PnP OS = Yes in BIOS, disabling the BIOS’s IRQ assignment, then
NT4 will not see most PCI cards.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Don Burn” wrote in message news:xxxxx@ntdev…
> Not so, I used /PCILOCK on NT4 for a failover system because otherwise NT
> would take two identical systems and set the IRQ’s and resources diferent!
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> >> Sorry Anton this is incorrect. Windows over the years has ignored the
> >> BIOS
> >> this is why there is /PCILOCK among other things.
> >
> > NT4 always obeyed the BIOS PCI IRQ settings, but NT4 was pre-ACPI OS.
> >
> > –
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
>
>
>

14

> Every PCI devices has its own corresponding interrupt assignment entry in MP

Configuration Table.

Am I wrong that the OS can patch this table to some extent using ACPI method
calls?

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

15

There is, Mark. For XP and earlier systems, I wrote the code in such
a way that sharing was encouraged, as that helped laptops (the
majority of ACPI machines at the time) keep interrupts free for PCMCIA
cards and such. For Vista I (and others) changed it so that sharing
was less strongly encouraged.

This has all been hashed over many times in this newsgroup. For a
long thread on the topic, look at the early 2002 archives and search
for “Oshins 9.”

  • Jake Oshins
    Windows Interrupt Guy

“Roddy, Mark” wrote in message
news:xxxxx@ntdev…
> So in that case Vista would be doing a better job at resource
> allocation, right?
>
> Perhaps I am missing your point. By the way, it is rather unlikely
> that
> there are any MSI capable devices on the OP’s system with MSI
> enabled
> drivers, so there has to be some other explanation for why on the
> same
> platform the XP driver has shared interrupts and the Vista driver
> does
> not. One possible explanation is that you are simply wrong about
> bios
> hardwiring.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@hotmail.com
> Sent: Tuesday, March 18, 2008 9:41 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] ISR routine returns FALSE
>
>> Vista appears to have done a better job at resource allocation and
> your device does
>> not have a shared interrupt.
>
> IRQ sharing has nothing to do with the OS - the OS gets all info
> about
> IRQs from BIOS tables, and it has to respect this info when dealing
> with interrupts . If BIOS says that IRQ X is shared by PCI devices
> A, B
> and C (I assume interrupt is asserted via pin, rather MSI), then the
> OS
> has no choice but to allocate and map resources the way BIOS says.
> Therefore, as long as target devices are not MSI-capable, it does
> not
> matter whether the target OS is XP or Vista. The only reason why
> there
> is less interrupt sharing under Vista is because it supports MSI, so
> that it can program MSI-capable device to raise interrupts via
> Message
> Address and Message data registers, rather than via pin. Therefore,
> as
> long as our imaginary devices A, B and C are MSI-capable, they have
> a
> chance to get dedicated vector under Vista but have to share IRQ
> under
> XP…
>
> Anton Bassov
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

16

Actually, Don, while /PCILOCK may have had some effect on the values
in Base Address Registers in NT 4 (I don’t remember, but let’s assume
it did for this discussion) I’m quite certain that it had no effect on
interrupt assignment in NT 4.

NT 4 interrupt assignment was purely a matter of reading what the BIOS
put in the various tables and using those values. There was no
re-assignment. I wrote the first NT code that rebalanced interrupts
for NT 5.

(Phew… You guys are making me go back 12 years here.)

  • Jake Oshins
    Windows Interrupt Guy

“Don Burn” wrote in message news:xxxxx@ntdev…
> Not so, I used /PCILOCK on NT4 for a failover system because
> otherwise NT would take two identical systems and set the IRQ’s and
> resources diferent!
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
>>> Sorry Anton this is incorrect. Windows over the years has ignored
>>> the BIOS
>>> this is why there is /PCILOCK among other things.
>>
>> NT4 always obeyed the BIOS PCI IRQ settings, but NT4 was pre-ACPI
>> OS.
>>
>> –
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>
>
>

17

Anton, this isn’t strictly true. The algorithms were changed in Vista
to share less often even without MSI.

In the example you give below, it’s likely that devices A, B and C
aren’t all connected to the same “wire” where “wire” might be an
actual PCI signal or just a register within the chipset for a PCIe
device. Let’s assume that A and B are wired together and C is wired
separately. The OS then has a choice between setting up the IRQ
routing device to either put A and B and C all on the same IRQ (either
PIC or I/O APIC) or put them on separate IRQs. A and B will never be
able to be separated. They must always share, since the motherboard
designer only laid down enough IRQ routing wires for two “groups” of
devices. But C can be independently assigned.

(The actual truth is that most motherboards have at least four routing
groups, if not eight these days. You can see this if you look at the
ACPI tables. And some machines route in PIC mode while they have
static routing in APIC mode. Other machines have dynamic routing in
both PIC and APIC mode.)

The bottom line for the Original Poster is that his device will have
to share interrupts in some machines and not others and more often
with XP than Vista. He must handle sharing correctly, because he will
find machines that must share, regardless of which OS is installed.

As I said in response to Mark, this is all well-covered in the
archives. See early 2002.

  • Jake Oshins
    Windows Interrupt Guy

wrote in message news:xxxxx@ntdev…
>> Vista appears to have done a better job at resource allocation and
>> your device does
>> not have a shared interrupt.
>
> IRQ sharing has nothing to do with the OS - the OS gets all info
> about IRQs from BIOS tables, and it has to respect this info when
> dealing with interrupts . If BIOS says that IRQ X is shared by PCI
> devices A, B and C (I assume interrupt is asserted via pin, rather
> MSI), then the OS has no choice but to allocate and map resources
> the way BIOS says. Therefore, as long as target devices are not
> MSI-capable, it does not matter whether the target OS is XP or
> Vista. The only reason why there is less interrupt sharing under
> Vista is because it supports MSI, so that it can program MSI-capable
> device to raise interrupts via Message Address and Message data
> registers, rather than via pin. Therefore, as long as our imaginary
> devices A, B and C are MSI-capable, they have a chance to get
> dedicated vector under Vista but have to share IRQ under XP…
>
> Anton Bassov
>
>

18

The OS (in this case, Windows) ignores the MP Configuration Table
entirely, at least when ACPI is enabled, which is all the time these
days. The reason is that the MP Configuration Table cannot be updated
at run time with new information and thus it can’t deal with new PCI
busses which are hot-plugged. (This happens both on laptops with
docking stations and on high-end servers.)

All information comes from the ACPI tables, which are considerable
more complex than the MP tables. And, yes, ACPI methods can tell the
BIOS how the OS wants the routing done and the BIOS can use the
interpreted code in the tables to carry out those wishes and make the
router reflect those choices.

  • Jake Oshins
    Windows Interrupt Guy

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>> Every PCI devices has its own corresponding interrupt assignment
>> entry in MP
>>Configuration Table.
>
> Am I wrong that the OS can patch this table to some extent using
> ACPI method
> calls?
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

19

I’m very curious about the role BIOS plays nowadays. I hear thousands of times that Windows or Linux does not relay on BIOS to supply any service. So BIOS is just a boot loader?

2008-03-18??“Don Burn” wrote:

wrote in message news:xxxxx@ntdev…
>> Vista appears to have done a better job at resource allocation and your
>> device does
>> not have a shared interrupt.
>
> IRQ sharing has nothing to do with the OS - the OS gets all info about
> IRQs from BIOS tables, and it has to respect this info when dealing with
> interrupts . If BIOS says that IRQ X is shared by PCI devices A, B and C
> (I assume interrupt is asserted via pin, rather MSI), then the OS has no
> choice but to allocate and map resources the way BIOS says. Therefore, as
> long as target devices are not MSI-capable, it does not matter whether
> the target OS is XP or Vista. The only reason why there is less interrupt
> sharing under Vista is because it supports MSI, so that it can program
> MSI-capable device to raise interrupts via Message Address and Message
> data registers, rather than via pin. Therefore, as long as our imaginary
> devices A, B and C are MSI-capable, they have a chance to get dedicated
> vector under Vista but have to share IRQ under XP…
>

Sorry Anton this is incorrect. Windows over the years has ignored the BIOS
this is why there is /PCILOCK among other things.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

20

Surely the modern OSes rely on ACPI table and ACPI bytecode from the BIOS,
but the machine code from the BIOS is never executed after the kernel is loaded
(with the exception of int 10h in Windows for some older video chips, usually
for power management on them).

For instance, int 13h is never used after the kernel is in memory.

I even have doubts that on x64-capable machine the BIOS contains any x64
mode code.

This is architecturally correct. The role of the firmware is to abstract
any motherboard-specific and chipset-specific stuff, not to be the lower layer
of the OS.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com