Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Monthly Seminars at OSR Headquarters

East Coast USA
Windows Internals and SW Drivers, Dulles (Sterling) VA, 13 November 2017

Kernel Debugging & Crash Analysis for Windows, Nashua (Amherst) NH, 4 December 2017

Writing WDF Drivers I: Core Concepts, Nashua (Amherst) NH, 8 January 2018

WDF Drivers II: Advanced Implementation Techniques, Nashua (Amherst) NH, 15 January 2018


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 4  
05 Jan 17 14:13
ntdev member 167993
xxxxxx@gmail.com
Join Date:
Posts To This List: 17
Different interrupt handling behavior on different PCs with same PCIe devices.

I'm getting different behaviors on two differnet PCs with respect to how my ISR is called. Both systems are running the same version of Windows Embedded, the same version of my driver, and are using the same version of my PCIe device, however, the PCs themselves are from different vendors with different internal hardware. On the system I was developing on, my ISR would be called, I'd read the my device's interrupt status register, clear out any pending interrupts, and push any further processing to various DPCs. Whenever my ISR would be called, the status register would always contain a non-zero value indicating that an interrupt was pending. On this other system I loaded my driver and PCIe device on, the ISR would be called and the interrupt status register would sometimes contain a 0 value, indicating that there is no interrupt currently pending. Then the ISR would be called again but this time, the status register would contain a non-zero value indicating that an interrupt is pending. While running the user application to process data on the PCIe device, I would get this behavior during the entire time it's running; ISR called with a 0 value in the interrupt status register, then later on, the ISR would be called with a non-zero value in the interrupt status register. On my development PC, I have yet to see in my traces a 0 value in the interrupt status register. Why would the ISR be called when my device didn't appear to raise an interrupt? Why would a different PC with the same version of Windows cause this behavior to occur?
  Message 2 of 4  
05 Jan 17 14:21
ntdev member 167993
xxxxxx@gmail.com
Join Date:
Posts To This List: 17
Different interrupt handling behavior on different PCs with same PCIe devices.

After additional reading, I think I answered my own question. I failed to mention that I have two identical PCIe devices in each PC. On my development PC, each device has different IRQ value, whereas on the other PC, they share the same IRQ value. Would this be the reason for why I sometimes see my ISR called for a device but there is no pending interrupt?
  Message 3 of 4  
05 Jan 17 14:35
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Different interrupt handling behavior on different PCs with same PCIe devices.

<quote> On this other system I loaded my driver and PCIe device on, the ISR would be called and the interrupt status register would sometimes contain a 0 value, indicating that there is no interrupt currently pending. Then the ISR would be called again but this time, the status register would contain a non-zero value indicating that an interrupt is pending </quote> This is the definition of how things work when you have two devices that share a single interrupt. Your driver has two devices under its control, and two devices are connected to one interrupt. When the interrupt occurs, Windows doesn't know which device is interrupting. It's your driver's job to determine this! So, when your ISR is invoked, the FIRST step you do is check to see "Is my device interrupting?" If it's not, you return FALSE from your ISR. If your device IS interrupting, you continue to process the interrupt (save the reason for the interrupt, acknowledge it so that the device stops interrupting, and then queue a DPC for ISR if you have more work to do). Sharing interrupts on PCI (and on LBI emulation on PCIe) is an inherent part of the standard. Note that you can share interrupts with other devices, not just other instances of your own device. So... be sure you're handling your interrupt correctly. One final note: If this is a WDM driver you're writing, make sure you check your device's power state in your ISR before you check to see if your device is interrupting. Consider what happens if your device is powered down (in D3, let's say) and you read your device's Interrupt Request Register to see if your "Interrupt Request" bit is set. You know what's going to happen, right? No? Well, I'll tell you... when you read the register on your powered down device, chances are you're going to read back all bits set. So it'll LOOK like your device is interrupting, even though it's in D3. And THAT will lead to all sorts of bad things. Peter OSR @OSRDrivers
  Message 4 of 4  
05 Jan 17 14:57
ntdev member 167993
xxxxxx@gmail.com
Join Date:
Posts To This List: 17
Different interrupt handling behavior on different PCs with same PCIe devices.

Thanks for the reply, Peter. On Thu, Jan 5, 2017 at 2:33 PM, <xxxxx@osr.com> wrote: > <quote> > On this other system I loaded my driver and PCIe device on, the ISR would > be > called and the interrupt status register would sometimes contain a 0 value, > indicating that there is no interrupt currently pending. Then the ISR > would be > called again but this time, the status register would contain a non-zero > value > indicating that an interrupt is pending > </quote> <...excess quoted lines suppressed...> --
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 02:40.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license