Re: [PATCH] Re: [Xen-devel] Time went backwards

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 14 Mar 2006, at 15:43, Rik van Riel wrote:

> > > Actually, we come into timer_interrupt() sometimes with
> > > blocked + stolen > delta_cpu, so the bugfix is valid.
> > >
> > > I just no longer understand how we can get into this
> > > situation...
> > Could be due to horrendous clock jitter across CPUs.
> Not on a single CPU system ;)
Hmmm... well, a few suggestions:
 1. The first do-while loop in timer_interrupt() in time-xen.c aims to 
get a consistent snapshot of blocked, stolen and delta_cpu, by checking 
timestamp-info version numbers  in the two while predicates. I just 
added a rmb() to time_values_up_to_date() -- required for absolute 
accuracy and will also act as a compiler barrier too. But the 
likelihood of gcc having moved that test earlier is very small I think. 
:-) If it had, though, you could end up with a later snapshot of 
stolen/blocked than of delta_cpu, which would be bad.
 2. Maybe the time synchronising code in Xen is broken. I tested it 
pretty hard when I implemented it, but you never know. It would be bad 
if time could step backwards during local_time_calibration() in 
xen/arch/x86/time.c. It might be worth doing a before-and-after check 
in that function (e.g., see whether value returned by get_s_time() gets 
smaller).
This bug can't be *that* hard to find on a single CPU system. :-)

 -- Keir


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