From: john stultz <johnstul@us.ibm.com>
To: Bernhard Schmidt <berni@birkenwald.de>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: Clock jumps
Date: Thu, 27 May 2010 12:08:04 -0700 [thread overview]
Message-ID: <AANLkTindrSuRdOI30l4P5XMuUVv3j7Zso9fMi1xREb3A@mail.gmail.com> (raw)
In-Reply-To: <htmdsk$9kn$1@dough.gmane.org>
On Thu, May 27, 2010 at 11:32 AM, Bernhard Schmidt <berni@birkenwald.de> wrote:
> Alexander Graf <agraf@suse.de> wrote:
>> Do you have ntpd running inside the guest? I have a bug report lying
>> around about 2.6.33 with kvm-clock jumping in time when ntpd is used:
>> https://bugzilla.novell.com/show_bug.cgi?id=582260
>
> I want to chime in here, I have a very similar problem, but not with
> ntpd in the guest.
>
> The host was a HP ProLiant DL320 G5p with a Dualcore Xeon3075. System
> was a Debian Lenny with a custom 2.6.33 host kernel and a custom
> qemu-kvm 0.11.0 .deb ported from Ubuntu. The host is synced with ntpd.
>
> The guests are various Debian Lenny/Squeeze VMs, with a custom kernel
> (2.6.33 at the moment) with kvm-clock. Exclusively amd64 guest
> kernels, but one system has i386 userland.
>
> With this setup once in a while (maybe every other week) one VM would
> have a sudden clock jump, 6-12 hours into the future. No kernel messages
> or other log entries than applications complaining about the clock jump
> after the fact. Other VMs were unaffected.
>
> Yesterday I did an upgrade to Debian Squeeze. This involved a new
> qemu-kvm (0.12.4), but not a new host kernel. I also upgraded the guest
> kernels from 2.6.33 to 2.6.33.4.
>
> First of all, after the reboot the host clock was totally unreliable. I
> had a constant skew of up to five seconds per minute in the host clock,
> which of course affected the VMs as well. This problem went away when I
> changed from tsc into hpet on the host. The host does CPU frequency
> scaling which is, as far as I know, known to affect TSC stability. I
> think I remember messages about tsc being unstable in earlier boots,
> maybe the detection did just not work this time.
I'd be very interested in hearing more about the host side issue. So
this happened with the same kernel that you were using before, with no
trouble?
Could you also send dmesg output from this boot? And if you can find
any older dmesg logs to compare with, send those too?
thanks
-john
next prev parent reply other threads:[~2010-05-27 19:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <loom.20100524T171038-56@post.gmane.org>
2010-05-25 6:21 ` Clock jumps Gleb Natapov
2010-05-26 17:10 ` Orion Poplawski
2010-05-26 17:31 ` Alexander Graf
2010-05-26 17:50 ` Orion Poplawski
2010-05-26 22:55 ` Orion Poplawski
2010-05-27 18:32 ` Bernhard Schmidt
2010-05-27 19:08 ` john stultz [this message]
2010-05-27 21:48 ` Bernhard Schmidt
2010-05-28 0:00 ` john stultz
2010-05-28 0:33 ` Bernhard Schmidt
2010-05-28 0:46 ` john stultz
2010-05-27 21:53 ` Zachary Amsden
2010-05-27 22:12 ` Bernhard Schmidt
2010-05-27 22:20 ` Zachary Amsden
2010-05-27 22:22 ` Zachary Amsden
2010-06-02 22:54 ` Orion Poplawski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTindrSuRdOI30l4P5XMuUVv3j7Zso9fMi1xREb3A@mail.gmail.com \
--to=johnstul@us.ibm.com \
--cc=berni@birkenwald.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).