USB Interrupt endpoint processing starved



This is somewhat of a follow up from a previous thread called 'USB
interrupt endpoint limitations'.

The components:
- My user mode code
- My own USB device driver.
- The MS USB controller driver
- My own device firmware.

Scenario:
- I have user mode code that is responding to data from the interrupt
endpoint in one thread context.
- The user code continuously makes queries to the USB device via the
bulk endpoint in another thread context.
- The USB device contains a circular buffer of host bound data waiting
for the USB controller to poll every 1ms.

Issue:
- Only on some computers, the USB controller is not polling data on
the interrupt endpoint of the USB device fast enough such that the
device's circular buffer overflows.

Additional:
- From my timing data I do not see any significant delays between
sequential events.
- After the buffer overflow is detected the user mode code stops
processing the bulk endpoint and I see a flood of interrupt endpoint
activity that empties the USB device buffer.
- I've verified that the USB controller is not polling the USB device
by using a hardware USB sniffer between the PC and USB device.
- I've already tried using multiple pending IRPs in the driver. No
change in behavior.
- I'm pretty sure I'm not blocking anything unduly in the user mode
code.
- In user mode if I call Sleep() for 1 to 4 milliseconds between bulk
endpoint reads and writes my buffer overflow problem goes away.

Conclusion:
- It appears to me that the continuous activity on the bulk endpoint
starves cpu cycles from the interrupt endpoint polling of USB
controller driver.

Questions:
- Can someone verify that this is possible?
- Can someone tell me how to get the USB controller to prioritize the
servicing of the interrupt endpoints regardless of other application
activity?
- The buffer overflow does not occur when I have trace output being
displayed in the console window of the user mode code. Q: Could the
forced context switching to paint the console window be causing the
USB controller driver to be given extra cpu cycles due to the way the
process scheduling works?

Thanks,
J.R. Heisey
Synaptics, Inc.
.



Relevant Pages