From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Tumanov Subject: Re: time freeze on save/restore, x86_64 Date: Wed, 10 Feb 2010 19:32:28 -0500 Message-ID: <2453e2901002101632k78f36f69m3883c739556424f0@mail.gmail.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1303604736==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org --===============1303604736== Content-Type: multipart/alternative; boundary=001636417e8f2b736e047f484931 --001636417e8f2b736e047f484931 Content-Type: text/plain; charset=ISO-8859-1 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 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@eu.citrix.com] > > Sent: Wednesday, February 10, 2010 5:09 PM > > To: Alexey Tumanov; xen-devel@lists.xensource.com > > 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" 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@lists.xensource.com > > http://lists.xensource.com/xen-devel > --001636417e8f2b736e047f484931 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable we're maintaining a patch queue on top of this specific c/set, and reba= sing the patch queue carries engineering overhead and testing. But if there= 's a small number of changesets that fixes the problem, perhaps we coul= d backport them?

Alex.

On 10 February 2010 19:22, Dan = Magenheimer <dan.magenheimer@oracle.com> wrote:
> Is behaviour different if you put a line 'tsc_mo= de=3D2' 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? =A0There'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. =A0If 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@eu.citrix.com]
> Sent: Wednesday, February 10, 2010 5:09 PM
> To: Alexey Tumanov; x= en-devel@lists.xensource.com
> Subject: Re: [Xen-devel] time freeze on save/restore, x86_64
>
> Is behaviour different if you put a line 'tsc_mode=3D2' in you= r domain
> config
> file as passed to 'xm create'?
>
> =A0-- Keir
>
> On 10/02/2010 23:51, "Alexey Tumanov" <atumanov@gmail.com> 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 da= te
> (referring
> > to /etc/localtime) and gettimeofday() (issuing a gettimeofday
> syscall)
> > repeatedly report unchanging values for tens of seconds:
> > debian:/var/tmp# ./timer
> > time: sec=3D1265844232, usec=3D728054
> > debian:/var/tmp# ./timer
> > time: sec=3D1265844232, usec=3D728054
> > debian:/var/tmp# ./timer
> > time: sec=3D1265844232, usec=3D728054
> > 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 =3D total of 8 exec= ution
> 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<= br> > futile - it
> > fires non-stop.
> >
> > Does anybody have any suggestions? In my case, it is not just a T= SC
> skew - the
> > clock stalls for quite an extended period of time, while the rest= ored
> VM is
> > otherwise operational and responds to all sorts of commands unles= s
> 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@lists.xenso= urce.com
> htt= p://lists.xensource.com/xen-devel

--001636417e8f2b736e047f484931-- --===============1303604736== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============1303604736==--