time freeze on save/restore, x86_64

[Alexey Tumanov <atumanov@gmail.com>]

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

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: 1711 bytes --]

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

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