WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Workaround for buggy PIT


On 15 Mar 2006, at 19:52, Tomas Kopal wrote:

I was printing out real diff values (detecting min and max over periods
of time) and it varied about 40% around the latch value. I didn't want
to get too many false positives, so I set it to double the expected
value. As the problematic values tend to be quite high, I think this is
a safe threshold.

40% range is huge, given that Xen disables interrupts only for very short periods of time.

If you think that the timer ends up corrupting its count value, but continues counting in the mode we originally programmed it to, there would be no need for your patch to reprogram the timer. We could just clamp diff and let the timer continue to free-run from whatever value it corrupted itself to. Would that simpler patch, with no reprogramming, work for you?

I agree with your suspicion that this may be a channel-0 problem. The 40% value range points at some serious weirdness.

As for other timer problems -- the really common one (latched reads do not latch, so you get inconsistent 16-bit reads) don't long-term affect our time stability. We end up out by a few hundred microseconds on that read of the clock, but the 16-bit timer value doesn't wrap or anything really bad like that, so we can recover. Phew. :-)

 -- Keir


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

<Prev in Thread] Current Thread [Next in Thread>