x86: Skip late calibration if our reference timer has low quality

[markj]

Summary

Some AMD Geode-based systems end up using the 8254 PIT to calibrate the
TSC during late calibration, which doesn't work because that
timecounter's mask (65535) is much smaller than its frequency (1193182).
Moreover, early calibration is done against the 8254 timer anyway.

Work around the problem by simply using early calibration results if no
high-quality timecounters exist.

PR: 260868
Fixes: 22875f88799e ("x86: Implement deferred TSC calibration")
Reported and tested by: [e-mail], Stefan Hegnauer <[e-mail]>

[cperciva]

Some AMD Geode-based systems end up using the 8254 PIT to calibrate the
TSC during late calibration, which doesn't work because that
timecounter's mask (65535) is much smaller than its frequency (1193182).
Moreover, early calibration is done against the 8254 timer anyway.

Hmm, not sure this makes perfect sense. Even if we end up using the i8254 here, a 1000 ms delay will give us a more accurate calibration than a 100 ms delay... notwithstanding the issues with the timer overflowing, of course.

Once I redo the calibration code (soon, hopefully!) this overflow issue should go away and then I think this can be removed.

[markj]

In D33730#762717, @cperciva wrote:

Some AMD Geode-based systems end up using the 8254 PIT to calibrate the
TSC during late calibration, which doesn't work because that
timecounter's mask (65535) is much smaller than its frequency (1193182).
Moreover, early calibration is done against the 8254 timer anyway.

Hmm, not sure this makes perfect sense. Even if we end up using the i8254 here, a 1000 ms delay will give us a more accurate calibration than a 100 ms delay...

Might be that we should use a 1000ms delay on i386 to mitigate this. In practice (i.e., on the two systems where the problem was reported and for which I have dmesgs), the difference in calibrated frequencies is reasonably small: 16.5KHz where the reported frequency is 498.06MHz.

notwithstanding the issues with the timer overflowing, of course.

Once I redo the calibration code (soon, hopefully!) this overflow issue should go away and then I think this can be removed.

That'd be fine with me. As you note this change is a bit of a hack; I'm comfortable with it since we almost always have a high-quality timecounter available to calibrate against anyway, but an approach which avoids the overflow is better.