>>The documentation for InterruptSynchronizePerMessage says "the Storport
driver calls the
>miniport driver’s HwMSInterruptRoutine routine at IRQL <= DISPATCH without
acquiring
>any interrupt spin locks. Is it correct or doc bug?
Its a documentation bug! The HwMSInterruptRoutine will be called at DIRQL
even if you set InterruptSynchronizePerMessage
Regards,
Gokul T V
On Thu, Oct 28, 2010 at 4:16 AM, wrote:
> Isn’t storport MSI routine actually called in a DPC which could be delayed
> by other DPCs and ISRs?
>
> The documentation for InterruptSynchronizePerMessage says "the Storport
> driver calls the miniport driver’s HwMSInterruptRoutine routine at IRQL <=
> DISPATCH without acquiring any interrupt spin locks. Is it correct or doc
> bug?
>
> —
> 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
>
> I don’t think this is true for MSI-X.
Am I wrong that all MSI have this word as an argument to the ISR routine?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
I admit that didn’t spend a LOT of time reading the code, but really looked to me like the port driver just did a couple of quick checks (such as to see if interrupts were enabled on the adapter) and then called the MiniPort ISR. It IS possible, of course, that I’m misreading or looking at the wrong thing.
Thanks Gokul. I THINK you’re right… is this from your experience, so you can say for sure? Somebody should submit that to the bug bash, it’s certainly a pretty serious bug if it’s true.
Peter
OSR
I’ve already submitted this bug to bug-bash :).
>is this from your experience, so you can say for sure? Somebody should
>submit that to the bug bash, it’s certainly a pretty serious bug if it’s
true.
I can say for sure. With WinDBG and couple of experiments with
StorportAcquireMSILock(), I’ve observed the following behavior.
-
With InterruptSyncAll, all the Message for that adapter shares a single
Interrupt-spinlock. Storport acquires this lock before calling MSI-Isr - so
that all Message interrupts are serialized.
-
With InterruptSyncPerMsg, each Message for that adapter will have an
unique Interrupt-spinlock. Say if Message-2 has interrupted, storport
acquires Interrupt-spinlock of Message-2 and calls MSI-Isr (so MSI-Isr will
be called at DIRQL only!!). So Message-2 interrupts are serialized, but
other messages from that adapter can still interrupt!
Regards,
Gokul T V
On Thu, Oct 28, 2010 at 6:39 PM, wrote:
>
>
> I admit that didn’t spend a LOT of time reading the code, but really looked
> to me like the port driver just did a couple of quick checks (such as to see
> if interrupts were enabled on the adapter) and then called the MiniPort ISR.
> It IS possible, of course, that I’m misreading or looking at the wrong
> thing.
>
>
>
> Thanks Gokul. I THINK you’re right… is this from your experience, so you
> can say for sure? Somebody should submit that to the bug bash, it’s
> certainly a pretty serious bug if it’s true.
>
> Peter
> OSR
>
> —
> 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
>
Excellent, thanks for clarifying.
Unfortunately, that leaves us in the position where we still cannot account for the behavior of the OP’s driver.
The only thing that *I* can think of that could account for the increased latency is one or more higher IRQL interrupts occurring. And those ISR’s taking a LOOOONG time.
Of course, I’m not sure how this could relate to opening a file for sync or async I/O.
There’s something here that we’re missing (or that we’re not being told)…
Peter
OSR
Thanks a lot, Gokul and Peter.
I will keep looking for the root cause(s) in the issue. Hopefully, I can share something convincing with you guys some day.