* Re: [PATCH] x86/tsc: Use hard-coded crystal clock for Skylake mobile [not found] ` <87eerr3ppb.fsf@nanos.tec.linutronix.de> @ 2020-05-11 7:38 ` Paul Menzel 2020-05-11 8:45 ` Radoslaw Biernacki 2020-05-11 9:36 ` Peter Zijlstra 0 siblings, 2 replies; 5+ messages in thread From: Paul Menzel @ 2020-05-11 7:38 UTC (permalink / raw) To: Thomas Gleixner, x86 Cc: Radoslaw Biernacki, Ross Zwisler, Daniel Drake, Andy Lutomirski, Borislav Petkov, H . Peter Anvin, Peter Zijlstra, Len Brown, linux, Rafael J . Wysocki, Thorsten Leemhuis, LKML Dear Thomas, Thank you for the quick reply. Am 11.05.20 um 09:17 schrieb Thomas Gleixner: > Paul Menzel <pmenzel@molgen.mpg.de> writes: > > please send patches to LKML and not offlist. Sorry about that. From `MAINTAINERS` I thought x86@kernel.org is wanted. Other subsystems list LKML explicitly there. >> From: Radoslaw Biernacki <biernacki@google.com> >> >> @@ -636,10 +636,24 @@ unsigned long native_calibrate_tsc(void) >> * Denverton SoCs don't report crystal clock, and also don't support >> * CPUID.0x16 for the calculation below, so hardcode the 25MHz crystal >> * clock. >> + * Also estimation code is not reliable and gives 1.5% difference for >> + * tsc/clock ratio on Skylake mobile. Therefore below is a hardcoded >> + * crystal frequency for Skylake which was removed by upstream commit >> + * "x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency" >> + * This is temporary workaround for bugs: >> + * b/148108096, b/154283905, b/146787525, b/153400677, b/148178929 >> + * chromium/1031054 >> */ >> - if (crystal_khz == 0 && >> - boot_cpu_data.x86_model == INTEL_FAM6_ATOM_GOLDMONT_D) >> - crystal_khz = 25000; >> + if (crystal_khz == 0) { >> + switch (boot_cpu_data.x86_model) { >> + case INTEL_FAM6_SKYLAKE_MOBILE: >> + crystal_khz = 24000; /* 24.0 MHz */ >> + break; >> + case INTEL_FAM6_ATOM_GOLDMONT_X: >> + crystal_khz = 25000; /* 25.0 MHz */ >> + break; >> + } > > Aside of being a workaround for Google issues which are probably caused > by broken BIOSes Even if it was caused by broken firmware, wouldn’t Linux’ no regression policy still consider this a regression as user should be able to the Linux kernel “no matter what”? > that patch is broken. > > INTEL_FAM6_ATOM_GOLDMONT_D != INTEL_FAM6_ATOM_GOLDMONT_X Good catch. The commit didn’t apply cleanly to the master branch, and I missed this. I’ll wait for Radoslaw to comment before proceeding further with this. Kind regards, Paul ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] x86/tsc: Use hard-coded crystal clock for Skylake mobile 2020-05-11 7:38 ` [PATCH] x86/tsc: Use hard-coded crystal clock for Skylake mobile Paul Menzel @ 2020-05-11 8:45 ` Radoslaw Biernacki 2020-05-11 12:34 ` Thomas Gleixner 2020-05-11 9:36 ` Peter Zijlstra 1 sibling, 1 reply; 5+ messages in thread From: Radoslaw Biernacki @ 2020-05-11 8:45 UTC (permalink / raw) To: Paul Menzel Cc: Thomas Gleixner, x86, Ross Zwisler, Daniel Drake, Andy Lutomirski, Borislav Petkov, H . Peter Anvin, Peter Zijlstra, Len Brown, Linux Upstreaming Team, Rafael J . Wysocki, Thorsten Leemhuis, LKML On Mon, May 11, 2020 at 9:38 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote: > > Dear Thomas, > > > Thank you for the quick reply. > > Am 11.05.20 um 09:17 schrieb Thomas Gleixner: > > > Paul Menzel <pmenzel@molgen.mpg.de> writes: > > > > please send patches to LKML and not offlist. > > Sorry about that. From `MAINTAINERS` I thought x86@kernel.org is wanted. > Other subsystems list LKML explicitly there. > > >> From: Radoslaw Biernacki <biernacki@google.com> > >> > >> @@ -636,10 +636,24 @@ unsigned long native_calibrate_tsc(void) > >> * Denverton SoCs don't report crystal clock, and also don't support > >> * CPUID.0x16 for the calculation below, so hardcode the 25MHz crystal > >> * clock. > >> + * Also estimation code is not reliable and gives 1.5% difference for > >> + * tsc/clock ratio on Skylake mobile. Therefore below is a hardcoded > >> + * crystal frequency for Skylake which was removed by upstream commit > >> + * "x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency" > >> + * This is temporary workaround for bugs: > >> + * b/148108096, b/154283905, b/146787525, b/153400677, b/148178929 > >> + * chromium/1031054 > >> */ > >> - if (crystal_khz == 0 && > >> - boot_cpu_data.x86_model == INTEL_FAM6_ATOM_GOLDMONT_D) > >> - crystal_khz = 25000; > >> + if (crystal_khz == 0) { > >> + switch (boot_cpu_data.x86_model) { > >> + case INTEL_FAM6_SKYLAKE_MOBILE: > >> + crystal_khz = 24000; /* 24.0 MHz */ > >> + break; > >> + case INTEL_FAM6_ATOM_GOLDMONT_X: > >> + crystal_khz = 25000; /* 25.0 MHz */ > >> + break; > >> + } > > > > Aside of being a workaround for Google issues which are probably caused > by broken BIOSes > > Even if it was caused by broken firmware, wouldn’t Linux’ no regression > policy still consider this a regression as user should be able to the > Linux kernel “no matter what”? > > > that patch is broken. > > > > INTEL_FAM6_ATOM_GOLDMONT_D != INTEL_FAM6_ATOM_GOLDMONT_X > > Good catch. The commit didn’t apply cleanly to the master branch, and I > missed this. > > I’ll wait for Radoslaw to comment before proceeding further with this. We found that regression only on specific SKU which was used in one model of ChromeBook. What's interesting is that some other SKU is fine. The consequences of this are rather not trivial, so this was considered a quickfix and temporary till we develop something better. In contrast to ChromeOs, I know that there is no way of finding if there are in fact regressions on generic kernel in the field (this is SKU dependent), but we also think that this problem should be addressed in a better way (if possible). We plan to work on this. Any help is welcome. > > > Kind regards, > > Paul ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] x86/tsc: Use hard-coded crystal clock for Skylake mobile 2020-05-11 8:45 ` Radoslaw Biernacki @ 2020-05-11 12:34 ` Thomas Gleixner 2020-05-11 15:39 ` Radoslaw Biernacki 0 siblings, 1 reply; 5+ messages in thread From: Thomas Gleixner @ 2020-05-11 12:34 UTC (permalink / raw) To: Radoslaw Biernacki, Paul Menzel Cc: x86, Ross Zwisler, Daniel Drake, Andy Lutomirski, Borislav Petkov, H . Peter Anvin, Peter Zijlstra, Len Brown, Linux Upstreaming Team, Rafael J . Wysocki, Thorsten Leemhuis, LKML Radoslaw Biernacki <biernacki@google.com> writes: > We found that regression only on specific SKU which was used in one > model of ChromeBook. > What's interesting is that some other SKU is fine. > > The consequences of this are rather not trivial, > so this was considered a quickfix and temporary till we develop > something better. > In contrast to ChromeOs, I know that there is no way of finding if > there are in fact regressions on generic kernel in the field (this is > SKU dependent), > but we also think that this problem should be addressed in a better > way (if possible). Fix the BIOS to setup the CPUID/MSRs correctly? Thanks, tglx ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] x86/tsc: Use hard-coded crystal clock for Skylake mobile 2020-05-11 12:34 ` Thomas Gleixner @ 2020-05-11 15:39 ` Radoslaw Biernacki 0 siblings, 0 replies; 5+ messages in thread From: Radoslaw Biernacki @ 2020-05-11 15:39 UTC (permalink / raw) To: Thomas Gleixner Cc: Paul Menzel, x86, Ross Zwisler, Daniel Drake, Andy Lutomirski, Borislav Petkov, H . Peter Anvin, Peter Zijlstra, Len Brown, Linux Upstreaming Team, Rafael J . Wysocki, Thorsten Leemhuis, LKML On Mon, May 11, 2020 at 2:34 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > Radoslaw Biernacki <biernacki@google.com> writes: > > We found that regression only on specific SKU which was used in one > > model of ChromeBook. > > What's interesting is that some other SKU is fine. > > > > The consequences of this are rather not trivial, > > so this was considered a quickfix and temporary till we develop > > something better. > > In contrast to ChromeOs, I know that there is no way of finding if > > there are in fact regressions on generic kernel in the field (this is > > SKU dependent), > > but we also think that this problem should be addressed in a better > > way (if possible). > > Fix the BIOS to setup the CPUID/MSRs correctly? > > Thanks, > > tglx Yes of course, but "if possible" might mean we would not be able to fix the BIOS. Anyway, let me see what actually can be done. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] x86/tsc: Use hard-coded crystal clock for Skylake mobile 2020-05-11 7:38 ` [PATCH] x86/tsc: Use hard-coded crystal clock for Skylake mobile Paul Menzel 2020-05-11 8:45 ` Radoslaw Biernacki @ 2020-05-11 9:36 ` Peter Zijlstra 1 sibling, 0 replies; 5+ messages in thread From: Peter Zijlstra @ 2020-05-11 9:36 UTC (permalink / raw) To: Paul Menzel Cc: Thomas Gleixner, x86, Radoslaw Biernacki, Ross Zwisler, Daniel Drake, Andy Lutomirski, Borislav Petkov, H . Peter Anvin, Len Brown, linux, Rafael J . Wysocki, Thorsten Leemhuis, LKML On Mon, May 11, 2020 at 09:38:34AM +0200, Paul Menzel wrote: > Sorry about that. From `MAINTAINERS` I thought x86@kernel.org is wanted. > Other subsystems list LKML explicitly there. Not sure what you're reading but: X86 ARCHITECTURE (32-BIT AND 64-BIT) M: Thomas Gleixner <tglx@linutronix.de> M: Ingo Molnar <mingo@redhat.com> M: Borislav Petkov <bp@alien8.de> M: x86@kernel.org R: "H. Peter Anvin" <hpa@zytor.com> L: linux-kernel@vger.kernel.org S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core F: Documentation/devicetree/bindings/x86/ F: Documentation/x86/ F: arch/x86/ Explicitly lists LKML, also note how x86@kernel.org is M not L. It is in fact a mail alias for just a few people, it is _NOT_ a list. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-05-11 15:39 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20200509113717.9084-1-pmenzel@molgen.mpg.de> [not found] ` <87eerr3ppb.fsf@nanos.tec.linutronix.de> 2020-05-11 7:38 ` [PATCH] x86/tsc: Use hard-coded crystal clock for Skylake mobile Paul Menzel 2020-05-11 8:45 ` Radoslaw Biernacki 2020-05-11 12:34 ` Thomas Gleixner 2020-05-11 15:39 ` Radoslaw Biernacki 2020-05-11 9:36 ` Peter Zijlstra
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.