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>, Alexey Tumanov <atumanov@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] time freeze on save/restore, x86_64
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Wed, 10 Feb 2010 16:22:50 -0800 (PST)
Cc:
Delivery-date: Wed, 10 Feb 2010 16:23:56 -0800
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
> Is behaviour different if you put a line 'tsc_mode=2' in your domain
> config file as passed to 'xm create'?

Keir --

C/s 19603 I think predates all of the tsc work, though the problem
might be related to timer_mode.

Alexey --

Why such an old changeset?  There's been a LOT of work on time since then.
If you are using a released product by a vendor with this changeset,
you might want to check with that vendor.  If not, and you aren't
able to update to a newer Xen, or if you update and it doesn't
fix the problem, please reply again.

Dan

> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Wednesday, February 10, 2010 5:09 PM
> To: Alexey Tumanov; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] time freeze on save/restore, x86_64
> 
> 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

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