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

[Thomas Gleixner]

On Sat, 18 May 2019, Konstantin Khlebnikov wrote:

> On 18.05.2019 18:17, Thomas Gleixner wrote:
> > 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?
> 
> In general this is very rare event.
> 
> This exact pattern have been seen ten times or so on several servers with
> Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz
> (this custom built platform with chipset Intel C610)
> 
> and haven't seen for previous generation
> Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
> (this is another custom built platform)

Same chipset? Note the HPET is part of the chipset not of the CPU.

> Link was in patch: https://lore.kernel.org/patchwork/patch/667413/

Hmm. Not really helpful either.

> > > 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.
> 
> ACPI power management timer is a pretty standard x86 hardware.

Used to be.

> But my patch should work for any platform with any second reliable
> clocksource.

Which is close to zero if PM timer is not exposed.

> If there is no second clocksource my patch does noting:
> watchdog_backup stays NULL and backup_consent always true.

That still does not justify the extra complexity for a few custom built
systems.

Thanks,

	tglx