>From what I know, you'll just have to put up with it for now. Also, I
believe that ntpdate showing positive offsets means that the clock is
running slower. Run the date command before the ntpdate one to check
what the guest clock is at before the NTP update.
On 11/9/05, [EMAIL PROTECTED] <[EMAIL
Hi!
I checked my QEMU and I found the same Problems. I'm running SLES9 (x86) on
an SLES9 (ppc) host. The target clock runs faster(? I've got positive
offsets running ntpdate ?) than the host clock. I've tried severel kernel
parameters (eg. clock=pit or clock=pmtmr) without any success.
The timin
Hi,
people have had this problem with SpeedStep machines, where it is
related to qemu timing being based on CPU cycle count, which is thereby
messed up.
Since it seems to occur with frequency scaling disabled as well, could
this be related to running on a HyperThreading CPU? Not sure what
happens
Alexander Toresson gmail.com> writes:
> time flies by at 5x the speed it should.
> PS. I'm susprised nobody has seen this problem before. Is it just me
> who experience it?
No, I experience this as well.
I'm running Qemu 0.7.2 with Linux 2.6.14 (vanilla kernel) as host OS and Windows
XP Profes
