| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Xen 3.2.2 - Timer ISR/0: Time went backwards
> Btw., does -unstable exhibit the same behavior?
Yes if you are able to reproduce the problem on a very recent unstable
(or on 4.0 when it is released), it would be very interesting to
see the results of this run in dom0:
xm debug-key t; xm dmesg | tail -2
or just do the t into the debug console that you did before.
In fact if on your system you can do:
watch "xm debug-key t; xm dmesg | tail -2"
and watch for dynamic patterns, that might shed some light as well.
(E.g. what values are growing, does it grow continuously or
spurt every N seconds, etc.)
(Note that the output from this is different and less useful
prior to 4.0.)
This will tell us if one of the physical cpu's tsc's has gone bonkers
or if the problem is elsewhere.
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Jan Beulich
> Sent: Tuesday, August 05, 2008 1:04 AM
> To: Christopher S. Aker
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Xen 3.2.2 - Timer ISR/0: Time went backwards
>
>
> This looks very similar to bug report we've got from IBM I'm currently
> trying to research (difficult, as I can't touch the
> hardware). What I know
> so far is that we're losing, starting a few seconds after
> dom0 boot began,
> 20-50+% timer interrupts. The moment this rate exceeds about 50%,
> platform time calibration breaks (as it sets the timer to
> half the overflow
> period). Since jiffies aren't used much elsewhere, this loss
> of timer ticks
> doesn't seem to matter much elsewhere.
>
> I've got no real clue so far *why* there's such a high rate
> of lost interrupts,
> though. The only (albeit small, since appearing very
> unlikely) possibility
> would be frequent and extensive SMM entries after ACPI mode got
> enabled on the system.
>
> Btw., does -unstable exhibit the same behavior?
>
> Jan
>
> >>> "Christopher S. Aker" <caker@xxxxxxxxxxxx> 04.08.08 20:51 >>>
> Hardware:
> Xen: 3.2.1-rc2 64bit
> dom0: 2.6.18.8 at changeset 622, PAE
>
> # xm dmesg | grep -e sync -e timer
> (XEN) checking TSC synchronization across 8 CPUs: passed.
> (XEN) Platform timer overflows in 234 jiffies.
> (XEN) Platform timer is 3.579MHz ACPI PM Timer
> (XEN) Machine check exception polling timer started.
>
> Spools one of these to console every few seconds:
>
> Timer ISR/0: Time went backwards: delta=-4270576170971
> delta_cpu=254829029 shadow=2037844042151244163 off=261710497
> processed=2037848312989081849 cpu_processed=2037844042158081849
> 0: 2037844042158081849
> 1: 2037828468354081849
> 2: 2037848312989081849
> 3: 2037837726866081849
> 4: 2037842059197081849
> 5: 2037840075526081849
> 6: 2037845844663081849
> 7: 2037841593777081849
>
> A few t's into Xen's console:
>
> (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to
> switch input
> to DOM0)
> (XEN) Min = 2037829427350793281 ; Max = 2037848310626701146 ; Diff =
> 18883275907865 (18883275907 microseconds)
> (XEN) Min = 2037829428349256182 ; Max = 2037848311625163843 ; Diff =
> 18883275907661 (18883275907 microseconds)
> (XEN) Min = 2037829428565188930 ; Max = 2037848311841096807 ; Diff =
> 18883275907877 (18883275907 microseconds)
>
> This particular box does this with 3.2.0 - 3.2.2-rc2. I have another
> box doing the same thing, except the delta is more sane (0 - 2
> microseconds), however eventually dom0 freezes.
>
> -Chris
>
>
> _______________________________________________
> 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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home