Re: time freeze on save/restore, x86_64

[Alexey Tumanov <atumanov@gmail.com>]

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

we're maintaining a patch queue on top of this specific c/set, and rebasing
the patch queue carries engineering overhead and testing. But if there's a
small number of changesets that fixes the problem, perhaps we could backport
them?

Alex.

On 10 February 2010 19:22, Dan Magenheimer <dan.magenheimer@oracle.com>wrote:

> > 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@eu.citrix.com]
> > Sent: Wednesday, February 10, 2010 5:09 PM
> > To: Alexey Tumanov; xen-devel@lists.xensource.com
> > 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@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.
> > >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 4726 bytes --]

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

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