Problem with KeStallExecutionProcessor in Windows 2000??


I have just sent the following message
Has anyone had similar problems with KeStallExecutionProcessor in Windows
Does any have a better email address to send bug reports to?

I have been doing some testing with a Windows NT Kernel Mode Driver under
both NT 4.0 and 2000. The driver is developed using VC++ 6.0 SP3 and the NT
4 DDK.

In order to time a hardware device we use on the LPT port we use
KeStallExecutionProcessor to provide a fairly accurate delay when clocking
data to/from the device. When used in 2000 the devices takes at least twice
as long to perform it’s commands.

On investigating I have found the following call -
KeStallExecutionProcessor( 50 ); - takes 50 microseconds under NT and 200
microseconds under 2000, This is affecting the timing of the device.

void DES_Delay10MicroTest()

if( (lpPort = DES_FindLptPort( 0x378 )) )
unsigned char chOld, chHi, chLo;
int loop;
chOld = PortRead( lpPort, 2, 0 );

chHi = chOld & 0x57;
chLo = (chOld | 0x08) & 0x5F;

for( loop = 0; loop < 5; loop++ )
PortWrite( lpPort, 2, chHi, 0 );
KeStallExecutionProcessor( DESDK2_TESTDELAY_TIME );
PortWrite( lpPort, 2, chLo, 0 );
KeStallExecutionProcessor( DESDK2_TESTDELAY_TIME );

PortWrite( lpPort, 2, chOld, 0 );

This functions modifies the state of pin 17 on the LPT port at hardware
address 0378, it switches HI->LO five times with a 50us pulse length.

The function DES_FindLptPort retrieves a pointer to a port information
descriptor which is initialise during driver startup. The functions PortRead
and PortWrite use the port info descriptor to wrap the READ_PORT_UCHAR and
WRITE_PORT_UCHAR kernel functions.


A logic analyzer is used to monitor pin 17 on the port and capture state
changes, using the analyzer shows the very significant difference between NT
4.0 and 2000. ± 5% would be acceptible. +300% is NOT acceptible.

Alun Carp