Prev: Programming an auto power-on timer
Next: OS x64 Identification
From: alex on 8 Apr 2010 05:02

Hi,
I'm currently analyzing a problem on a Windows XP PC with custom
hardware attached on PCI-E. The hardware is an acquisition device (with
its driver), and when the acquisition is started, the system time isn't
updated correctly (time flows slower than on an external clock).
Restarting the PC, the time is again right, I guess because the time is
read from the RTC at startup.
As far as I can understand, the system time is updated by the OS on
every periodic tick, so I guess that some clock interrupt is lost, but
what can perturb these interrupts? Judging from IRQLs, the only levels
above CLOCK1_LEVEL are IPI_LEVEL and POWER_LEVEL, and I don't see any
reason why those interrupts could be generated in an anomalous number
when the acquisition is active. A standard device driver shouldn't be
allowed to block the clock interrupt, should it?
Is there any tool or technique I can use to understand what's going on?

Bye
Alex
From: alex on 9 Apr 2010 02:50
On 08/04/2010 11.02, alex wrote:

> As far as I can understand, the system time is updated by the OS on
> every periodic tick, so I guess that some clock interrupt is lost, but
> what can perturb these interrupts? Judging from IRQLs, the only levels
> above CLOCK1_LEVEL are IPI_LEVEL and POWER_LEVEL, and I don't see any
> reason why those interrupts could be generated in an anomalous number
> when the acquisition is active. A standard device driver shouldn't be
> allowed to block the clock interrupt, should it?
Another info is that disabling chip multiprocessing in the BIOS the
problem disappears. In other words it seems that the system time is
wrong only when more than 1 CPU is enabled. Could it be that IPIs block
clock interrupts?

Bye
Alex
 | 
Pages: 1
Prev: Programming an auto power-on timer
Next: OS x64 Identification