Re: time freeze on save/restore, x86_64

[Alexey Tumanov <atumanov@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2252 bytes --]

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@eu.citrix.com> 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@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 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.
> >
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 3053 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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