lkml.org 
[lkml]   [2008]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Regression in 2.6.27 caused by commit bfc0f59


On Tue, 2 Sep 2008, Thomas Gleixner wrote:
>
> On that box, the PIT is probably real hardware or a damned good
> emulation. When you look at the 10 loop values you see that it does
> 50% perfectly fine calibration loops. The others are just SMI
> interruptions caused by random unknown crap in the BIOS.

Ok, so I actually think I know how to resolve the problem once and for
all.

The solution is actually fairly simple: we use the HPET algorithm. The
reason the HPET algorithm is so robust is that

- we can actually read the frequency from the HPET itself

- we also simply just read the counter values from the HPET, and so it
doesn't really matter how much time has passed between the two reads,
it only matters that _some_ time has passed, and that we pick _one_
stable read that we can associate with a TSC value.

But the thing is, the exact same thing is actually true of the old PIT
timer too - except we simply don't take advantage of it. The PIT timer has
a very well known frequency value (PIT_TICK_RATE: 1193180 Hz), and we can
trivially read the counter value too.

But the thing is, that for some forgotten reason, that's not actually what
we do. Instead of reading the counter value, we wait until it counts down
to zero, and read the output value instead. So instead of having a nice
and dependable counter that ticks down (16 bits of precision), we actually
use a _single_ bit of result, and depend on reading the TSC at the same
time.

That's kind of sad.

I'll try to whip up a test-patch to do this in a smarter way.

Linus


\
 
 \ /
  Last update: 2008-09-03 00:25    [W:0.199 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site