VirtualBox

Ticket #8707 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

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

Reported by: ricebowl Owned by:
Priority: major Component: VMM/HWACCM
Version: VirtualBox 4.0.6 Keywords: HPET,timer,clock
Cc: Guest type: Windows
Host type: Windows

Description

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 = 232, 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.

Attachments

VBox.log Download (47.0 KB) - added by ricebowl 3 years ago.
Log file
timetest.cpp Download (2.3 KB) - added by ricebowl 3 years ago.
Test program

Change History

Changed 3 years ago by ricebowl

Log file

Changed 3 years ago by ricebowl

Test program

comment:1 Changed 3 years ago by nike

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

comment:2 Changed 3 years ago by nike

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

comment:3 Changed 3 years ago by frank

 Here is a test build containing the fix.

comment:4 Changed 3 years ago by frank

Does that build fix your problem?

comment:5 Changed 3 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

comment:6 Changed 3 years ago by ricebowl

  • Status changed from closed to reopened
  • Resolution fixed deleted

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

comment:7 Changed 3 years ago by frank

  • Priority changed from minor to major
  • Version changed from VirtualBox 4.0.4 to VirtualBox 4.0.6

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).

comment:8 Changed 3 years ago by 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 232 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.

comment:9 Changed 3 years ago by ni81036

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.

comment:10 Changed 3 years ago by ni81036

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.

comment:11 Changed 3 years ago by wacher

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

comment:12 Changed 3 years ago by 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.

comment:13 Changed 3 years ago by frank

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

comment:14 Changed 3 years ago by 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.

comment:15 Changed 3 years ago by frank

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

comment:16 Changed 3 years ago by 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)

comment:17 Changed 3 years ago by frank

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

comment:18 Changed 3 years ago by 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.

comment:19 Changed 3 years ago by frank

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

comment:20 Changed 3 years ago by 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.

comment:21 Changed 3 years ago by ricebowl

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

comment:22 Changed 3 years ago by frank

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

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

comment:23 Changed 3 years ago by frank

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use