User space code and not getting read requests fast enough.

rob18767

Member
Joined
Jul 2, 2020
Posts
10
I have a piece of PCIe hardware, that I designed, running on an FPGA. The FPGA has 2 ping pong buffers and interrupts every 80ms after filling up one buffer, which tells Windows to go away and process this data (KMDF driver), while this is being processed the other buffer starts to fill to be processed on the next interrupt etc. etc.

The processing is done by a user mode process that accesses this data via a read request within the 80ms time frame (terminates read request in DPC).

The kernel mode stuff is fine (interrupts firing at IRQL DIRQL and DPC at DPC priority with no DPCs nor interrupts being missed).

However the user mode process stops being able to supply read requests within the 80ms time frame after (weirdly) just over 24 hours. This causes a buffer to be missed (although it is forced into a ring buffer).

The user mode process logs the time when it eventually does try to service a read request post. I am going to use latencymon to try and track

1) Highest interrupt to process latency
2) Highest interrupt and DPC times.

That said.

Are there any applications that can be triggered to show what other processes are using the system at the time of the missed buffer.

I have procdump set using.

procdump -ma -i C;\dumps

However C:\dumps is empty after the missed buffer.

I am pretty sure there is some process that is stomping on my user mode process with a higher priority (I disabled Windows and Google Updaters). So I would like to find what this process is?

Any help is appreciated.

I am using Windows IoT 10 Enterprise Build 1809.

Thank you
 
This question would be better suited for the OSR forums since they deal with driver development issues on a regular basis.
 
This is a user space issue. The driver is working fine. The user space application cannot provide read requests fast enough to the driver.
 
I think xperf could be a solution to my problem... potentially

Is there anyway to get xperf to trace only after user space application throws an exception?

The user space application takes many hours to crash and xperf -on interrupt+dpc will make a ridiculously large file.
 
I would consider attaching a debugger to the process and then manually stepping through from when the exception occurs. You'll probably get much more useful information.
 
I would consider attaching a debugger to the process and then manually stepping through from when the exception occurs. You'll probably get much more useful information.

That does not help. Its seems that another process is starving our process of its IRQL time that it requires.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top