Re: [PATCH RFC] time: validate watchdog clocksource using second best candidate

[Thomas Gleixner <tglx@linutronix.de>]

On Wed, 15 May 2019, Konstantin Khlebnikov wrote:

> Timekeeping watchdog verifies doubtful clocksources using more reliable
> candidates. For x86 it likely verifies 'tsc' using 'hpet'. But 'hpet'
> is far from perfect too. It's better to have second opinion if possible.
> 
> We're seeing sudden jumps of hpet counter to 0xffffffff:

On which kind of hardware? A particular type of CPU or random ones?

> timekeeping watchdog on CPU56: Marking clocksource 'tsc' as unstable because the skew is too large:
> 'hpet' wd_now: ffffffff wd_last: 19ec5720 mask: ffffffff
> 'tsc' cs_now: 69b8a15f0aed cs_last: 69b862c9947d mask: ffffffffffffffff
> 
> Shaohua Li reported the same case three years ago.
> His patch backlisted this exact value and re-read hpet counter.

Can you provide a reference please? Preferrably a lore.kernel.org/... URL

> This patch uses second reliable clocksource as backup for validation.
> For x86 this is usually 'acpi_pm'. If watchdog and backup are not consent
> then other clocksources will not be marked as unstable at this iteration.

The mess you add to the watchdog code is unholy and that's broken as there
is no guarantee for acpi_pm (or any other secondary watchdog) being
available.

If the only wreckaged value is always ffffffff then I rather reread the
hpet in that case. But not in the watchdog code, we need to do that in the
HPET code as this affects any other HPET user as well.

Thanks,

	tglx