[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 8 Aug 2019 22:36:47 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: "Lendacky, Thomas" <Thomas.Lendacky@....com>
cc: "Li, Aubrey" <aubrey.li@...ux.intel.com>,
Aubrey Li <aubrey.intel@...il.com>,
Daniel Drake <drake@...lessm.com>,
"x86@...nel.org" <x86@...nel.org>, Ingo Molnar <mingo@...hat.com>,
"H . Peter Anvin" <hpa@...or.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Endless Linux Upstreaming Team <linux@...lessm.com>
Subject: Re: setup_boot_APIC_clock() NULL dereference during early boot on
reduced hardware platforms
Tom,
On Thu, 1 Aug 2019, Lendacky, Thomas wrote:
> On 8/1/19 5:13 AM, Thomas Gleixner wrote:
> > 2.1.9 Timers
> >
> > Each core includes the following timers. These timers do not vary in
> > frequency regardless of the current P-state or C-state.
> >
> > * Core::X86::Msr::TSC; the TSC increments at the rate specified by the
> > P0 Pstate. See Core::X86::Msr::PStateDef.
> >
> > * The APIC timer (Core::X86::Apic::TimerInitialCount and
> > Core::X86::Apic::TimerCurrentCount), which increments at the rate of
> > 2xCLKIN; the APIC timer may increment in units of between 1 and 8.
> >
> > The Ryzens use a 100MHz input clock for the APIC normally, but I'm not sure
> > whether this is subject to overclocking. If so then it should be possible
> > to figure that out somehow. Tom?
>
> Let me check with the hardware folks and I'll get back to you.
any update on this? The problem seems to come in from several sides now.
Thanks,
tglx
Powered by blists - more mailing lists