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

[Alexey Tumanov <atumanov@xxxxxxxxx>]

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@xxxxxxxxxxxxx> 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@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