Messages in this thread | | | Subject | Re: [PATCH] x86/hpet: Disable HPET on Intel Coffe Lake | From | Kai-Heng Feng <> | Date | Thu, 29 Aug 2019 22:13:32 +0800 |
| |
at 20:13, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 29 Aug 2019, Kai-Heng Feng wrote: > >> Some Coffee Lake platforms have skewed HPET timer once the SoCs entered >> PC10, and marked TSC as unstable clocksource as result. > > So here you talk about Coffee Lake and in the patch you use KABYLAKE.
Coffeelake has the same model number as Kabylake.
> >> Harry Pan identified it's a firmware bug [1]. >> >> To prevent creating a circular dependency between HPET and TSC, let's >> disable HPET on affected platforms. >> >> [1]: >> https://lore.kernel.org/lkml/20190516090651.1396-1-harry.pan@intel.com/ >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203183 > > Please use Link:// for reference not [1] and not Bugzilla:
Ok.
> >> +static const struct x86_cpu_id hpet_blacklist[] __initconst = { >> + { X86_VENDOR_INTEL, 6, INTEL_FAM6_KABYLAKE_MOBILE }, >> + { X86_VENDOR_INTEL, 6, INTEL_FAM6_KABYLAKE_DESKTOP }, > > So this disables HPET on all Kaby Lake variants not just on the affected > Coffee Lakes. I know that I rejected the initial patch with the random > stepping cutoff... > > https://lore.kernel.org/lkml/alpine.DEB.2.21.1904081403220.1748@nanos.tec.linutronix.de > > In the other attempt to 'fix' this I asked for clarification, but silence > from Intel after this: > > https://lore.kernel.org/lkml/alpine.DEB.2.21.1905182015320.3019@nanos.tec.linutronix.de > > Can Intel please provide some useful information about this finally?
Hopefully Intel can provide more info.
I know we should find the root cause rather than stopping at "it’s a firmware bug”, but users are already affected by this issue [1]. Is there any better short-term workaround?
[1] https://bugzilla.kernel.org/show_bug.cgi?id=204537
Kai-Heng
> > Thanks, > > tglx
| |