[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/599958
Title:
Timedrift
Absolutely, please close it.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/599958
Title:
Timedrift problems with Win7: hpet missing time drift fixups
Status in QEMU:
Incomplete
Bug
Looking through old bug tickets... can this issue still be reproduced
with the latest version of QEMU? Or could we close this ticket nowadays?
** Changed in: qemu
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
I google about an old link talk about this issue can be fixed by not
using virtio
http://forum.proxmox.com/archive/index.php/t-5783.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/599958
Title:
Forgot to add: Reproduced the above behavior in both 1.5.1 and 1.6.0.
Adding -no-hpet to commandline removed both problems (full disclosure:
this fix wasn't tested in 1.5.1 but I have no reason to believe behavior
would be different.)
--
You received this bug notification because you are a
Apparently this bug's still alive and kicking.
There's an obvious clock skew problem on Windows 7; in the Date Time
dialog, the clock jumps through seconds visibly too fast.
I also found a case where HPET bugs are causing a real problem: Terraria
(dedicated server) seems to be relying on
On Tue, Oct 01, 2013 at 09:34:06AM -, Ben A wrote:
Apparently this bug's still alive and kicking.
And no plans to fix it. Do not use hpet with windows guests this buys
you nothing.
There's an obvious clock skew problem on Windows 7; in the Date Time
dialog, the clock jumps through
Fair enough in itself, but if HPET is known to have problems with
arguably the most popular OS family to use as a guest, why is it
enabled by default?
On Tue, Oct 1, 2013 at 10:56 AM, Gleb Natapov g...@redhat.com wrote:
On Tue, Oct 01, 2013 at 09:34:06AM -, Ben A wrote:
Apparently this
On Tue, Oct 01, 2013 at 11:23:07AM -0500, Ben Root Anderson wrote:
Fair enough in itself, but if HPET is known to have problems with
arguably the most popular OS family to use as a guest, why is it
enabled by default?
Arguably :) But QEMU defaults are arguably far from been optimal for any
Agh, I forgot reply all.
Seems like something that should be changed, no? It would've saved me
a lot of headache if there was a switch e.g.
-optimize-for=[linux,winxp,
win7,etc] that changed the defaults to be
most accomodating to the specified OS as a guest.
On Tue, Oct 1, 2013 at 11:33 AM,
On Tue, Oct 01, 2013 at 11:36:39AM -0500, Ben Root Anderson wrote:
Agh, I forgot reply all.
I have to re reply now :)
Seems like something that should be changed, no? It would've saved me
a lot of headache if there was a switch e.g.
-optimize-for=[linux,winxp,
win7,etc] that changed the
-no-hpet works in every version of qemu/qemu-kvm that has included HPET
support. RHEL disables HPET support by default unlike qemu and qemu-
kvm.
I've updated the bug priority and title to reflect what the issue is.
We only support edge triggered interrupts with HPET which seems to be
what most
Sent patch http://patchwork.test.kernel.org/patch/2384/ to autotest and
will update the autotest server to reflect that option.
--
Timedrift problems with Win7: hpet missing time drift fixups
https://bugs.launchpad.net/bugs/599958
You received this bug notification because you are a member of
13 matches
Mail list logo
