The problem I am currently experiencing is on a driver I have ported over
from NT to XP. This driver makes use of KeStallExecutionProcessor(8) in a
DpcForIsr routine. The delay I need is 8 microseconds. I am getting
inconsistent results on XP on one motherboard (Intel BL440ZX w/ Celeron
366 Mhz processor – we have many in the field) which has worked fine for
years under NT4 with the old driver. The failure mode is too short a
stall time, but occurs very intermittently, averaging only once every
18,000 or so calls. Updating to XP Service Pack 1 had no impact.
On a second motherboard (RadiSys SF810 w/ Pentium3 600Mhz processor –
we’ve been shipping this one for about a year), it works fine both under
NT with the old driver and under XP with the new driver.
My measurements were made with a logic analyzer – when the failure
occurs, the delay time is found to be MUCH shorter than commanded (about
half), which results in my going to my hardware too early and bad things
happening after that.
Has anyone else experienced similar problems with
KeStallExecutionProcessor()?
Very strange. I stepped through the KeStallExecutionProcessor on my XP
machine here and, although the intro code seems to do a bit more than under
NT4, the basic idea is the same: a constant is loaded into EAX,
representing the number of instructions to execute to waste away a
microsecond, and then the code just loops around EAX times to waste the
time away. You can try checking the constant which is loaded in each case;
presumably, it should not differ for a given motherboard between NT4 and XP.
In any case, since all your processors seem to be pentium based, after
calling the Stall routine you can use the RDTSC instruction to verify
whether the right amount of time has indeed elapsed, and you can then
reenter the stall if necessary.
Avi
At 10:39 AM 2/14/2003 -0500, you wrote:
The problem I am currently experiencing is on a driver I have ported over
from NT to XP. This driver makes use of KeStallExecutionProcessor(8) in a
DpcForIsr routine. The delay I need is 8 microseconds. I am getting
inconsistent results on XP on one motherboard (Intel BL440ZX w/ Celeron
366 Mhz processor – we have many in the field) which has worked fine for
years under NT4 with the old driver. The failure mode is too short a
stall time, but occurs very intermittently, averaging only once every
18,000 or so calls. Updating to XP Service Pack 1 had no impact.
On a second motherboard (RadiSys SF810 w/ Pentium3 600Mhz processor –
we’ve been shipping this one for about a year), it works fine both under
NT with the old driver and under XP with the new driver.
My measurements were made with a logic analyzer – when the failure
occurs, the delay time is found to be MUCH shorter than commanded (about
half), which results in my going to my hardware too early and bad things
happening after that.
Has anyone else experienced similar problems with
KeStallExecutionProcessor()?
You are currently subscribed to ntdev as: xxxxx@excalibur.co.il
To unsubscribe send a blank email to xxxxx@lists.osr.com
What chipset were you using? We see failures like this whenever a new
chipset is introduced. We’ve hacked around most of the bugs we know about.
But new ones come up all the time.
Thanks,
Jake Oshins
Windows HAL Guy
wrote in message news:xxxxx@ntdev… > > The problem I am currently experiencing is on a driver I have ported over > from NT to XP. This driver makes use of KeStallExecutionProcessor(8) in a > DpcForIsr routine. The delay I need is 8 microseconds. I am getting > inconsistent results on XP on one motherboard (Intel BL440ZX w/ Celeron > 366 Mhz processor – we have many in the field) which has worked fine for > years under NT4 with the old driver. The failure mode is too short a > stall time, but occurs very intermittently, averaging only once every > 18,000 or so calls. Updating to XP Service Pack 1 had no impact. > > On a second motherboard (RadiSys SF810 w/ Pentium3 600Mhz processor – > we’ve been shipping this one for about a year), it works fine both under > NT with the old driver and under XP with the new driver. > > My measurements were made with a logic analyzer – when the failure > occurs, the delay time is found to be MUCH shorter than commanded (about > half), which results in my going to my hardware too early and bad things > happening after that. > > Has anyone else experienced similar problems with > KeStallExecutionProcessor()? > > >
The code that you’re describing is different from HAL to HAL. Your
description covers only the HALs that believe that the machine has three
fundamental underlying attributes:
The processor(s) run at a constant speed.
If there are multiple processors, they share a single clock source.
The RDTSC instruction works.
Other implementations tend to use clocks inside the chipset.
Jake Oshins
Windows HAL Guy
“Avi Shmidman” wrote in message news:xxxxx@ntdev… > > Very strange. I stepped through the KeStallExecutionProcessor on my XP > machine here and, although the intro code seems to do a bit more than > under > NT4, the basic idea is the same: a constant is loaded into EAX, > representing the number of instructions to execute to waste away a > microsecond, and then the code just loops around EAX times to waste the > time away. You can try checking the constant which is loaded in each > case; > presumably, it should not differ for a given motherboard between NT4 and > XP. > In any case, since all your processors seem to be pentium based, after > calling the Stall routine you can use the RDTSC instruction to verify > whether the right amount of time has indeed elapsed, and you can then > reenter the stall if necessary. > > - Avi > > > At 10:39 AM 2/14/2003 -0500, you wrote: > >The problem I am currently experiencing is on a driver I have ported over > >from NT to XP. This driver makes use of KeStallExecutionProcessor(8) in > >a > >DpcForIsr routine. The delay I need is 8 microseconds. I am getting > >inconsistent results on XP on one motherboard (Intel BL440ZX w/ Celeron > >366 Mhz processor – we have many in the field) which has worked fine for > >years under NT4 with the old driver. The failure mode is too short a > >stall time, but occurs very intermittently, averaging only once every > >18,000 or so calls. Updating to XP Service Pack 1 had no impact. > > > >On a second motherboard (RadiSys SF810 w/ Pentium3 600Mhz processor – > >we’ve been shipping this one for about a year), it works fine both under > >NT with the old driver and under XP with the new driver. > > > >My measurements were made with a logic analyzer – when the failure > >occurs, the delay time is found to be MUCH shorter than commanded (about > >half), which results in my going to my hardware too early and bad things > >happening after that. > > > >Has anyone else experienced similar problems with > >KeStallExecutionProcessor()? > > > > > >— > >You are currently subscribed to ntdev as: xxxxx@excalibur.co.il > >To unsubscribe send a blank email to xxxxx@lists.osr.com > > > > >
The board which is failing intermittently under Windows XP (but worked
fine under NT4) is an older Intel NLX motherboard (BL440ZX). Chipset is
–>
Intel 82440ZX AGPset (on the 66-Mhz host bus), consisting of:
Intel 82443ZX PCI/AGP controller (PAC)
Intel 82371EB PCI/ISA IDE Xcelerator (PIIX4E)
The “newer” board which works fine both under NT4 and XP is a RadiSys
microNLX motherboard (SF810). Chipset is –>
Intel 810 chipset comprising 2 parts -
. Graphics and memory controller hub (GMCH)
. I/O controller hub (ICH)
In addition, a National Semiconductor NS87200 ISA bridge is used to
support ISA devices via the riser card.
What would you recommend we do to get this working reliably under Windows
XP on the Intel BL440ZX motherboard??
I have some further observations from some overnight testing here by our
hardware engineer… The thing that’s weird about what we’re seeing is
that KeStallExecutionProcessor() works fine MOST of the time. That is,
most of the time we measure time values that are correct (but on the high
side) for what we program, i.e., when we run with a stall time of 8 usec,
we measure around 10 usec between the IOW and the IOR to our hardware.
For testing purposes, last night we changed the stall time to 20 usec, and
measured around 25 usec.
The interesting thing is, when it fails, we always measure around 5.5
usec, REGARDLESS OF what the programmed stall time is! The failure is
intermittent, but definitely occurs more frequently with shorter
programmed stall times. For example, when 8 usec was programmed, failure
intervals occurred at 4, 6, 11, 14, 24, 7 minute intervals (we repeat the
stall 1800 times in a minute). Changing to 20 usec yielded failure
intervals of 55, 380, 170, 62, 220, 189 minutes.