I've runned into a problem with our KMDF driver. It's for a USB device and
our client is using calling it in a loop while modifying the mmtimer. Here's
the sample code that runs into the problem:
for (;
{
CallOurUsbDeviceIoctl();
timeBeginPeriod(1); // High resolution
Sleep(1);
timeEndPeriod(1); // End high resolution
}
The problem is that this code seems to trigger the bug documented in
KB821893 (http://support.microsoft.com/kb/821893): "The system clock may run
fast when you use the ACPI power management timer as a high-resolution
counter". The clock runs a lot faster. With my poorly written CPU sucking
driver it runs 60 seconds on 38 real seconds.
To pinpoint the problem, I've used the well known OSR USB-FX2 kit and the
sample driver from the WDK (kmdf\osrusbfx2, both step4 and final). By adding
a loop around one of the sample calls and adding the multimedia timer code,
I can repeat the problem with this simple sample driver. Now I get 60
seconds on 56 real seconds.
Then I turn to the OSR WDM sample driver for this kit, add the same code to
the testprogram (needs some updates to work with the latest WDK) and the
problem is gone.
I can easily verify that the clock interrupt is higher with perfmon
(Interrupt/s) when using the high resolution code (that's the penalty one
get for using it). So I know that the high resoulution timer is running. I
have also verified that there's no problem with time when removing the high
resolution code.
I've tried to get my client to use one of the workarounds, but that
contradicts the recommendation in the SDKfor TimeBeginPeriod: "Call this
function immediately before using timer services, and call the timeEndPeriod
function immediately after you are finished using the timer services.", so
my client would not agree.
So my conclusion on this matter is that there is something in the KMDF
library that triggers the problem. Do I have to convert our KMDF driver to
WDM to get rid of the problem?
Regards
Carl-Magnus Segerlund
