RE: [Xen-devel] Timer going backwards and Unable to handle kernel NULLpointer

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>I've been seeing these pretty regularly on a single-socket dual-core Athlon
>system for the last couple of months, and only on Friday finally found time
>to start looking into these. Besides the messages above, I also see hangs
>in about every other boot attempt but only if I do *not* use serial output
>(which makes debugging a little harder), and never once initial boot finished
>- this is why I finally needed to find time to look into the problem. I shall
>note though that the kernel we use does not disable CONFIG_GENERIC_TIME
>and makes use of a Xen clocksource as posted by Jeremy among the
>paravirt ops patches.
>What happens when the hang occurs (in do_nanosleep context) is that the
>time read/interpolated from the Xen provided values is in the past compared
>to the last value read (and cached inside the kernel), resulting in a huge
>timeout value rather than the intended 50ms one.
>Without having collected data proving this (will do later today), I currently
>think that the interpolation parameters are too imprecise until the first time
>local_time_calibration() runs on each CPU, i.e. during little less than the 
>first
>second of dom0's life).

The box I'm looking at takes 600ms to enable ACPI mode, during which time
no interrupts get delivered. Since it is not having a (visible) HPET, it has to
use the PIT, the 16-bit counter of which manages to roll over 11 times during
this process. The result is that the TSC is considered running too fast and
hence getting slowed down. Since this slow-down doesn't happen at exactly
the time (it can't be expected to), one CPU starts reporting measurably
smaller nano-second time values than the other, hence monotonicity gets
violated pretty significantly.

I'm therefore considering:
- making the PIT timer recover from being disabled for periods longer than
  what the 16-bit counter can tolerate (by means of estimating the number
  of roll-overs based on the TSC) - this would probably work well close after
  boot or at any time all TSCs are sufficiently synchronized, but could go
  pretty wrong as the individual TSCs drift apart
- inventing a method in the kernel that can cover even significantly non-
  monotonic values interpolated on different CPUs (it is clear from the data
  collected that small deviations from monotonic values must be accounted
  for in any case, but that could be done by simply returning the most
  recently returned value in case it turns out that the interpolated value is
  smaller than that, so the issue is really how to reasonably bridge large
  gaps)

Suggestions/opinions?

Jan


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