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:20:26 -0500 Message-ID: <2453e2901002101620l2023ec11gae23741fda427665@mail.gmail.com> References: <2453e2901002101551x124e6915n9f20919a22cc6c4b@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0585134415==" 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: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org --===============0585134415== Content-Type: multipart/alternative; boundary=0016e65c884c1a31fe047f481e57 --0016e65c884c1a31fe047f481e57 Content-Type: text/plain; charset=ISO-8859-1 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 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" 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. > > > > > --0016e65c884c1a31fe047f481e57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable same behavior. But, according to this doc:
http://lists.xe= nsource.com/archives/html/xen-changelog/2009-12/msg00035.html
tsc_mo= de is a new feature in Xen-4? Xen-unstable c/s 19603 is roughly at 3.4.0 le= vel.

Thanks,
Alex.


On 10 February 2= 010 19:09, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
Is behaviour different if you put a line 'tsc_mode=3D2' in your dom= ain 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 kern= el 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 (r= eferring
> 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 execution= threads.
> Processor: Intel Xeon E5472 @ 3GHz
> Arch: x86_64
>
> I've seen some discussion about TSC skew, and tried setting clocks= ource to
> acpi instead of the default hpet - didn't help. I also tried echoi= ng "1" to
> /proc/sys/xen/independent_wallclock to no avail. Finally, no luck debu= gging
> with xen gdb, because setting a breakpoint in do_gettimeofday is futil= e - it
> fires non-stop.
>
> Does anybody have any suggestions? In my case, it is not just a TSC sk= ew - 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 the= y
> execute anything that translates into a nanosleep syscall. The latter,= of
> course, won't return until the clock starts going again.
>
> Thanks,
> Alex.
>



--0016e65c884c1a31fe047f481e57-- --===============0585134415== 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 --===============0585134415==--