Vista RTM 64-bit HPET jumps by 42 seconds approx. once per minute => Fixed in SVN

[ricebowl]

I am running a Vista SP2 64-bit host and Vista RTM 64-bit guest on an Athlon II X4 610e. I have observed in an application that I am writing that QueryPerformanceCounter() in the guest sometimes jumps forward by approx. 42 seconds. On the host it works correctly. The host is configured to use HPET and reports a timer frequency of ~14 MHz. The guest also configures itself to use HPET, but the timer frequency it reports is 100 MHz. I tried setting the processor affinity on the VirtualBox.exe process responsible for the VM, but it did not help. It turns out that 42 seconds * 100 MHz = 2^{32, and when I print out the results from QueryPerformanceCounter() in hexadecimal, it appears that the high 32-bits of the counter are occasionally incremented twice.}

I am not yet sure if this is a Windows bug, a VirtualBox bug, or something else. I am attaching my log file and the C code for my test program.

Some additional information that may be helpful: QueryPerformanceCounter() calls NtQueryPerformanceCounter() which calls KeQueryPerformanceCounter() in the kernel. KeQueryPerformanceCounter() checks the high-performance time source, and if it's HPET (which is true in my case), then it reads the current HPET time out of system memory.

[ricebowl]

Log file

[ricebowl]

Test program

[Nikolay Igotti]

Host HPET doesn't matter in this issue, as device is fully virtualized.

[Nikolay Igotti]

Thanks for the report, fix shall be available in SVN, please check and see if it fixes the issue.

[Frank Mehnert]

​Here is a test build containing the fix.

[Frank Mehnert]

Does that build fix your problem?

[ricebowl]

The issue is not fixed. I have not had time until now to test. I tried the new build, and the behavior still repros.

[Frank Mehnert]

Hmm, then there must be another bug in the HPET timer implementation. So I suggest to disable the HPET timer (VBoxManage modifyvm VMNAME --hpet off).

[ricebowl]

When I disable HPET, it does not seem to affect anything. VBoxManage claims that it's off, but the timer frequency is the same (100 MHz), and it still periodically skips forward 2^{32 ticks.}

I looked at the change in SVN, and it appears to address the possibility of sampling the two 32-bit halves during a roll-over. However, my issue cannot be caused by a race condition. If it were a race, then only time samples around the roll-over would be corrupt, and the timer would otherwise tick at the normal rate. I am seeing it tick at twice the normal rate. It appears that the high half is incremented twice every time the low half rolls over. For example, I sample 0x00000000FFFFFFFF followed by 0x0000000200000000. If it were a race, then I would either see 0x00000001FFFFFFFF or 0x0000000100000000.

I can only think of two scenarios: 1) Windows is counting interrupts, and somehow the interrupt gets delivered twice. 2) Windows is reading the raw HPET counter, and the double increment is from something inside VirtualBox.

[Nikolay Igotti]

HPET disable only works with PIIX chipset, with ICH9 it's always on. Interrupts at 100Mhz rate would kill any modern box, so I somewhat doubt that Windows counts interrupts for performance counters, at least directly. Good news, however, is that I'm able to reproduce your issue. Rewrote your test a bit, and see that jump is 4x of normal on my box, and usually happens once or twice during a minute. Issue looks rather interesting, so stay tuned.

[Nikolay Igotti]

Interesting, it seems issue is due to behavioral difference in ICH9 from standard HPET specification wrt 32-bit counter wraparound. Hopefully fixed in SVN (testcase works fine). Could you please test trunk build and see if it resolves issue for you too.

[wacher]

Maybe #8629 and this ticket are related to each other?

[ricebowl]

Unlike #8629, I am not experiencing stalls. The application that I am developing is seeing huge leaps in the HPET time, but apart from that I have not observed any adverse effects.

I am still waiting to test the new build, but the latest SVN commit I see is from April 18.

[Frank Mehnert]

Please try again now. The current code still has some issues but it would be interesting to get some feedback anyway.

[ricebowl]

I have not had a chance to set up the build environment to build from SVN; is there a build that I can download? Alternatively, is the fix incorporated in 4.0.6? I already have 4.0.6 installed. I will be away for a couple of weeks but will test when I get back.

[Frank Mehnert]

​This test build contains the fix. However, this is from trunk, so consider it more unstable than VBox 4.0.6.

[wacher]

Because I still believe that #8629 and this tickets are related to each other (not same but related) I tried frank's build. Unfortunatelly it crash at boot time, I can't test anything. (I tried three times) (host XP, guest W7)

[Frank Mehnert]

Thanks for testing. Could you test ​this build? It should be more stable and hopefully contains the correct fix.

[wacher]

I tested 4.0.7 r71573. I can't talk about #8707, but #8629 is still exists. System is stalled for 14 seconds then alive for 30 sec. 14 + 30, 14 + 30, 14 + 30 and so on, this is a recurring symptom. I measured the time with my simple watch not with a precise one, 14+30=44 sec cycle is very similar to ricebowl's 42 sec.

[Frank Mehnert]

ricebowl, please test the above test build when you find some time. Thank you!

[ricebowl]

The new build seems to fix the bug. I ran a modified version of my test program for almost 10 minutes, and the HPET stayed in sync with other time sources. I am going to mark this as fixed.

[ricebowl]

Nevermind. I guess you have to mark it as fixed. Anyway, I will close it once that option is available.

[Frank Mehnert]

Thanks for the feedback! The fix will be part of the next maintenance release.