From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: time freeze on save/restore, x86_64 Date: Thu, 11 Feb 2010 00:09:18 +0000 Message-ID: References: <2453e2901002101551x124e6915n9f20919a22cc6c4b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2453e2901002101551x124e6915n9f20919a22cc6c4b@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Alexey Tumanov , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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" 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. >