* time freeze on save/restore, x86_64
@ 2010-02-10 23:51 Alexey Tumanov
2010-02-11 0:09 ` Keir Fraser
0 siblings, 1 reply; 6+ messages in thread
From: Alexey Tumanov @ 2010-02-10 23:51 UTC (permalink / raw)
To: xen-devel
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: time freeze on save/restore, x86_64
2010-02-10 23:51 time freeze on save/restore, x86_64 Alexey Tumanov
@ 2010-02-11 0:09 ` Keir Fraser
2010-02-11 0:20 ` Alexey Tumanov
2010-02-11 0:22 ` Dan Magenheimer
0 siblings, 2 replies; 6+ messages in thread
From: Keir Fraser @ 2010-02-11 0:09 UTC (permalink / raw)
To: Alexey Tumanov, xen-devel@lists.xensource.com
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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: time freeze on save/restore, x86_64
2010-02-11 0:09 ` Keir Fraser
@ 2010-02-11 0:20 ` Alexey Tumanov
2010-02-11 0:32 ` Keir Fraser
2010-02-11 0:22 ` Dan Magenheimer
1 sibling, 1 reply; 6+ messages in thread
From: Alexey Tumanov @ 2010-02-11 0:20 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel@lists.xensource.com
[-- Attachment #1.1: Type: text/plain, Size: 2252 bytes --]
same behavior. But, according to this doc:
http://lists.xensource.com/archives/html/xen-changelog/2009-12/msg00035.html
tsc_mode is a new feature in Xen-4? Xen-unstable c/s 19603 is roughly at
3.4.0 level.
Thanks,
Alex.
On 10 February 2010 19:09, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> 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.
> >
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 3053 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: time freeze on save/restore, x86_64
2010-02-11 0:09 ` Keir Fraser
2010-02-11 0:20 ` Alexey Tumanov
@ 2010-02-11 0:22 ` Dan Magenheimer
2010-02-11 0:32 ` Alexey Tumanov
1 sibling, 1 reply; 6+ messages in thread
From: Dan Magenheimer @ 2010-02-11 0:22 UTC (permalink / raw)
To: Keir Fraser, Alexey Tumanov, xen-devel
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: time freeze on save/restore, x86_64
2010-02-11 0:22 ` Dan Magenheimer
@ 2010-02-11 0:32 ` Alexey Tumanov
0 siblings, 0 replies; 6+ messages in thread
From: Alexey Tumanov @ 2010-02-11 0:32 UTC (permalink / raw)
To: Dan Magenheimer; +Cc: xen-devel, Keir Fraser
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-02-11 0:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-10 23:51 time freeze on save/restore, x86_64 Alexey Tumanov
2010-02-11 0:09 ` Keir Fraser
2010-02-11 0:20 ` Alexey Tumanov
2010-02-11 0:32 ` Keir Fraser
2010-02-11 0:22 ` Dan Magenheimer
2010-02-11 0:32 ` Alexey Tumanov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).