[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
  • From: Alexey Tumanov <atumanov@xxxxxxxxx>
  • Date: Wed, 10 Feb 2010 19:32:28 -0500
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Delivery-date: Wed, 10 Feb 2010 16:32:50 -0800
  • 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=mmhx3dorxjOd88xsCLT1JMNUfyZp4Hz51gmngEQMvQjx1Qx3DJ4Imo/ABrhQt/oUpn qgRKm+bxB4ve7xilPmaP7hXR1Chew1hSidgroSHFas3KrghuaBQ1cyAZcs/iqNy2R00r pPDRe8z6gdCXK9kWqiqpJUPY/B2WQirQWYjkE=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

we're maintaining a patch queue on top of this specific c/set, and rebasing the patch queue carries engineering overhead and testing. But if there's a small number of changesets that fixes the problem, perhaps we could backport them?

Alex.

On 10 February 2010 19:22, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> 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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.