Re: apic and 8254 wraparound ...

[Pavel Machek]

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.
								Pavel
-- 
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/