This question is best asked as a hypothetical one… suppose I had two
devices each controlled by the same driver. Each device is a PCI adapter
that is wired to the same IRQ line. Now suppose I have some shared
driver data that I want both devices to access, but they will only ever
access it in their ISR (not just ‘only at DIRQL’ but really ‘only in the
ISR’). Do I need to protect this data with any sort of lock, given that
both ISR’s are for the same IRQ and therefore run at the same IRQL?
The only situation I can think of where this protection would be needed
is if the following series of events occurred:
- IRQ is asserted for device #1
- CPU#1 starts running the ISR for device #1
- IRQ is asserted for device #2
- CPU#2 starts running the ISR for device #2
Could that situation happen? I would have thought not. For starters, the
IRQ should remain asserted until the ISR finishes, which makes step 3
happening at that time impossible. But maybe I’m wrong… and the IRQ
get’s de-asserted when the ISR ack’s the interrupt in the PCI hardware.
In that case maybe it could happen?
Can someone enlighten me please?
Thanks
James
>(not just ‘only at DIRQL’ but really ‘only in the ISR’). Do I need to
protect this data with any sort of lock, given that
both ISR’s are for the same IRQ and therefore run at the same IRQL?
The fact that it’s the same ISR executing does not change anything, it’s
just a routine called on the CPU on which the interrupt
occurs. If you don’t know on what CPU your interrupt will occur, the answer
is yes unless you have an interrupt spinlock provided and you do not use
IoConnectInterruptEx to specify a ProcessorEnableMask (affinity) to have
the interrupt occur only on one particular processor.
//Daniel
This is what the synchronized IRQL and spinlock parameters are for when you connect the interrupt. Now the problem is collecting both pieces of interrupt information to find the max values b/c both devices will each receive their own async starts. You can handle this one of two ways
- wait for both devices to start and only connect the interrupt on both 1 and 2 when the 2nd arrives
- when the first is started, connect the interrupt. When the 2nd arrives, disconnect the first, compute max irql and then reconnect the 1st and connect the 2nd
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Tuesday, May 19, 2009 4:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] question about irq delivery
This question is best asked as a hypothetical one… suppose I had two
devices each controlled by the same driver. Each device is a PCI adapter
that is wired to the same IRQ line. Now suppose I have some shared
driver data that I want both devices to access, but they will only ever
access it in their ISR (not just ‘only at DIRQL’ but really ‘only in the
ISR’). Do I need to protect this data with any sort of lock, given that
both ISR’s are for the same IRQ and therefore run at the same IRQL?
The only situation I can think of where this protection would be needed
is if the following series of events occurred:
- IRQ is asserted for device #1
- CPU#1 starts running the ISR for device #1
- IRQ is asserted for device #2
- CPU#2 starts running the ISR for device #2
Could that situation happen? I would have thought not. For starters, the
IRQ should remain asserted until the ISR finishes, which makes step 3
happening at that time impossible. But maybe I’m wrong… and the IRQ
get’s de-asserted when the ISR ack’s the interrupt in the PCI hardware.
In that case maybe it could happen?
Can someone enlighten me please?
Thanks
James
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
Or just have a single device handle interrupts and instead distribute DPCs to the child devices
James Harper wrote:
This question is best asked as a hypothetical one… suppose I had two
devices each controlled by the same driver. Each device is a PCI adapter
that is wired to the same IRQ line.
What do you mean by that? Do you mean two devices sitting behind a
bridge but sharing a single PCI slot to the host? Or do you mean two
unrelated devices in two separate slots, but PnP has decided to set up
the routing so that they share the same IRQ?
Could that situation happen? I would have thought not. For starters, the
IRQ should remain asserted until the ISR finishes, which makes step 3
happening at that time impossible. But maybe I’m wrong… and the IRQ
get’s de-asserted when the ISR ack’s the interrupt in the PCI hardware.
In that case maybe it could happen?
It takes more than telling the device to de-assert the interrupt. The
interrupt controller has to re-enable this IRQ, and that won’t happen
until the ISR returns. That’s why people use DPCs; the DPC can continue
handling an interrupt, while allowing the interrupt to be re-armed.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> 1. IRQ is asserted for device #1
- CPU#1 starts running the ISR for device #1
- IRQ is asserted for device #2
- CPU#2 starts running the ISR for device #2
Could that situation happen? I would have thought not.
I think you are absolutely correct here…
For starters, the IRQ should remain asserted until the ISR finishes, which makes step
3 happening at that time impossible.
IIRC, as long as we are speaking about handling level-triggered interrupts on x86, IRQ will get de-asserted only when EOI gets issued - under Windows it happens only after ISR returns control…
Anton Bassov
> This is what the synchronized IRQL and spinlock parameters are for when you connect the interrupt.
The above statement describes how things are synchronized when IRQs are different - in this case, they,indeed, have to be synchronized. However, please don’t forget that James speaks about (probably infeasible) scenario when IRQ is the same. In this particular case the whole thing seems to synchronize itself…
Anton Bassov
> The fact that it’s the same ISR executing does not change anything,
…but the fact that IRQ happens to be the same as well is something that makes the whole thing truly unique…
Anton Bassov
True, if you use what I describe it does no harm and is now resilient to hw change or the OS magically giving you different DIRQLs.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Tuesday, May 19, 2009 1:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] question about irq delivery
This is what the synchronized IRQL and spinlock parameters are for when you connect the interrupt.
The above statement describes how things are synchronized when IRQs are different - in this case, they,indeed, have to be synchronized. However, please don’t forget that James speaks about (probably infeasible) scenario when IRQ is the same. In this particular case the whole thing seems to synchronize itself…
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
> True, if you use what I describe it does no harm and is now resilient to hw change or the OS
magically giving you different DIRQLs.
Well, in actuality, one just HAS to use what you had described, because, for the practical purposes, it would be just silly to assume the scenario James had mentioned.
In fact, the only possible way of how it may happen that I can see is the scenario when your controller just follows some industry specifications (for example, UHCI controller), so that all existing instances of a device in question will be handled by the same driver, no matter if it is on-board device or the one in PCI slot.
For example, let’s say I insert an additional USB controller into available PCI slot. I already have on-board EHCI with 4 companion UHCI controllers, so that all 4 PCI routing groups are already occupied by separate instances of UHCI. Therefore, adding yet another instance of UHCI will result in a situation
when two instances of UHCI have to signal interrupts via the same pin…
Anton Bassov
>
> True, if you use what I describe it does no harm and is now
resilient to hw
change or the OS
> magically giving you different DIRQLs.
Well, in actuality, one just HAS to use what you had described,
because, for
the practical purposes, it would be just silly to assume the scenario
James
had mentioned.
In fact, the only possible way of how it may happen that I can see is
the
scenario when your controller just follows some industry
specifications (for
example, UHCI controller), so that all existing instances of a device
in
question will be handled by the same driver, no matter if it is
on-board
device or the one in PCI slot.
For example, let’s say I insert an additional USB controller into
available
PCI slot. I already have on-board EHCI with 4 companion UHCI
controllers, so
that all 4 PCI routing groups are already occupied by separate
instances of
UHCI. Therefore, adding yet another instance of UHCI will result in a
situation
when two instances of UHCI have to signal interrupts via the same
pin…
Thanks Anton and everyone else. I now know a bit more than I did
yesterday 
James