WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] time freeze on save/restore, x86_64

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] time freeze on save/restore, x86_64
From: Alexey Tumanov <atumanov@xxxxxxxxx>
Date: Wed, 10 Feb 2010 19:20:26 -0500
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 10 Feb 2010 16:20:45 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xdnEP6oZjBn84j558b/EKyekQZQALGeWpp0Qvwt/OMA=; b=teJ70++g6wn9RA5abrDbvyJnp8fkkayhYjH2RrB58ikK1FaO1hJ6x1QKMzZrhaRoHL xoiZ/+V7xpAehzW9zybzDtvCSmY9sU8yeMBi6/woQaxbyf9NNpSFydk17YFTCAy4Om94 RAmdRTIGS3nAM6hFQaK7xfktUGcV1WZ01TC+M=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ws4batnZlaMC8paGxCG5XGC1JP50Mar9EUry18Wg0kkiFRd0/bvA55pC1tCyBTJOS0 DzaNZlCty7aEYIZIuDs1l/xQD4RB9rH7a4z3Jj3lnMHfHDdc9brxehPmSpk5hGqKdLYT IGJnBjMOtD+5zc3yORTWAQbWLK2wh01dOl5Ak=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C798FB2E.9C73%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <2453e2901002101551x124e6915n9f20919a22cc6c4b@xxxxxxxxxxxxxx> <C798FB2E.9C73%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
same behavior. But, according to this doc:
http://lists.xensource.com/archives/html/xen-changelog/2009-12/msg00035.html
tsc_mode is a new feature in Xen-4? Xen-unstable c/s 19603 is roughly at 3.4.0 level.

Thanks,
Alex.


On 10 February 2010 19:09, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
Is behaviour different if you put a line 'tsc_mode=2' in your domain config
file as passed to 'xm create'?

 -- Keir

On 10/02/2010 23:51, "Alexey Tumanov" <atumanov@xxxxxxxxx> wrote:

> Hi,
>
> I'm running xen-unstable c/s 19603 with a single 2.6.18.8-xen kernel image
> used for both dom0 and domUs. I'm experiencing a time freeze when I restore a
> domU checkpoint file on another physical host. Basically, both date (referring
> to /etc/localtime) and gettimeofday() (issuing a gettimeofday syscall)
> repeatedly report unchanging values for tens of seconds:
> debian:/var/tmp# ./timer
> time: sec=1265844232, usec=728054
> debian:/var/tmp# ./timer
> time: sec=1265844232, usec=728054
> debian:/var/tmp# ./timer
> time: sec=1265844232, usec=728054
> debian:/var/tmp# date
> Wed Feb 10 23:23:52 UTC 2010
> debian:/var/tmp# date
> Wed Feb 10 23:23:52 UTC 2010
> debian:/var/tmp# date
> Wed Feb 10 23:23:52 UTC 2010
>
> The timer (TSC??) springs back to life after 20-30 seconds.
> Hardware: Sun Fire X2250, 2 socket, quad-core = total of 8 execution threads.
> Processor: Intel Xeon E5472 @ 3GHz
> Arch: x86_64
>
> I've seen some discussion about TSC skew, and tried setting clocksource to
> acpi instead of the default hpet - didn't help. I also tried echoing "1" to
> /proc/sys/xen/independent_wallclock to no avail. Finally, no luck debugging
> with xen gdb, because setting a breakpoint in do_gettimeofday is futile - it
> fires non-stop.
>
> Does anybody have any suggestions? In my case, it is not just a TSC skew - the
> clock stalls for quite an extended period of time, while the restored VM is
> otherwise operational and responds to all sorts of commands unless they
> execute anything that translates into a nanosleep syscall. The latter, of
> course, won't return until the clock starts going again.
>
> Thanks,
> Alex.
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel