> Is behaviour different if you put a line 'tsc_mode=2' in your domain
> config file as passed to 'xm create'?
Keir --
C/s 19603 I think predates all of the tsc work, though the problem
might be related to timer_mode.
Alexey --
Why such an old changeset? There's been a LOT of work on time since then.
If you are using a released product by a vendor with this changeset,
you might want to check with that vendor. If not, and you aren't
able to update to a newer Xen, or if you update and it doesn't
fix the problem, please reply again.
Dan
> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Wednesday, February 10, 2010 5:09 PM
> To: Alexey Tumanov; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] time freeze on save/restore, x86_64
>
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home