Messages in this thread | | | Date | Sun, 26 Dec 2004 20:42:15 +0100 | From | Herbert Poetzl <> | Subject | Re: apic and 8254 wraparound ... |
| |
On Sun, Dec 26, 2004 at 07:08:06PM +0100, Pavel Machek wrote: > Hi! > > > > When you read one 8bit value from an 8254 timer the values latch for > > > read so that when you read the other half of the 16bit value you get the > > > value from the moment of the first read. On > > > neptune that didn't work right so you got halves of two differing > > > samples. That means the error would be worst case a bit under 300 (257 > > > for the wrap + a few for timing) > > > > okay, I still wasn't able to find the documentation > > at the intel site, but I could extrapolate the issue > > from your explanation (thanks by the way) > > > > get_8254_timer_count() reads lo byte first, then the > > high byte, so assuming that the latch doesn't work > > as expected on intel 430 NX and LX chipsets, can > > result in the following type of error: > > > > counter >= 2^8 * N, LO is read (for example 0) > > counter is decremented > > counter < 2^8 * N HI is read (N - 1) > > > > so the read value will be exactly 2^8 lower than > > expected (assumed that the counter doesn't do more > > than 256 counts between the two inb_p()s) > > > > second the wrap-around will always happen _after_ > > the counter reached zero, so we can further assume > > that the prev_count, has to be lower than 2^8, when > > we observe a wraparound (otherwise we don't care) > > > > let's further assume the counter does not decrement > > more than 2^7 between two consecutive gets, then we > > can change the wraparound check to something like > > this: > > > > curr_count = get_8254_timer_count(); > > > > do { > > prev_count = curr_count; > > redo: > > curr_count = get_8254_timer_count(); > > > > /* workaround for broken Mercury/Neptune */ > > if (prev_count - current_count >= 256) > > goto redo; > > > > /* ignore values far off from zero */ > > if (prev_count > 128) > > continue; > > > > } while (prev_count >= curr_count) > > > > > > basically the check for (prev_count > 128) can be > > removed but it feels a little more comfortable ... > > > > would such change be acceptable for mainline? > > Not sure... Reading time is quite performance critical; doing it twice > would be bad. It should be acceptable if it was only done on > Mercury/Neptune systems.
this important detail got lost over the thread
static void __init wait_8254_wraparound(void)
so I guess it should not be _too_ critical ;)
best, Herbert
> -- > People were complaining that M$ turns users into beta-testers... > ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |