Re: time freeze on save/restore, x86_64

[Keir Fraser <keir.fraser@eu.citrix.com>]

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.
>