From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Tumanov Subject: time freeze on save/restore, x86_64 Date: Wed, 10 Feb 2010 18:51:40 -0500 Message-ID: <2453e2901002101551x124e6915n9f20919a22cc6c4b@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2093961550==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============2093961550== Content-Type: multipart/alternative; boundary=00163646ba343eee6d047f47b7a4 --00163646ba343eee6d047f47b7a4 Content-Type: text/plain; charset=ISO-8859-1 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. --00163646ba343eee6d047f47b7a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I'm running xen-unstable c/s 19603 with a single 2.6.18.8-xe= n kernel image used for both dom0 and domUs. I'm experiencing a time fr= eeze when I restore a domU checkpoint file on another physical host. Basica= lly, both date (referring to /etc/localtime) and gettimeofday() (issuing a = gettimeofday syscall) repeatedly report unchanging values for tens of secon= ds:
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# d= ate
Wed Feb 10 23:23:52 UTC 2010
debian:/var/tmp# date
Wed Feb 10 23:23:52 UTC 2010
debian:/var/tmp# d= ate
Wed Feb 10 23:23:52 UTC 2010

The timer (TSC??) springs back t= o life after 20-30 seconds.
Hardware: Sun Fire X2250, 2 socket, quad-cor= e =3D total of 8 execution threads.
Processor: Intel Xeon E5472 @ 3GHz
Arch: x86_64

I've seen som= e discussion about TSC skew, and tried setting clocksource to acpi instead = of the default hpet - didn't help. I also tried echoing "1" t= o /proc/sys/xen/independent_wallclock to no avail. Finally, no luck debuggi= ng 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 ske= w - the clock stalls for quite an extended period of time, while the restor= ed 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.
--00163646ba343eee6d047f47b7a4-- --===============2093961550== 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 --===============2093961550==--