linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>
Cc: "Li, Aubrey" <aubrey.li@linux.intel.com>,
	Aubrey Li <aubrey.intel@gmail.com>,
	Daniel Drake <drake@endlessm.com>,
	"x86@kernel.org" <x86@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Endless Linux Upstreaming Team <linux@endlessm.com>
Subject: Re: setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms
Date: Thu, 8 Aug 2019 23:08:56 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1908082306220.2882@nanos.tec.linutronix.de> (raw)
In-Reply-To: <5bf28ba4-b7c1-51de-88ae-feebae2a28db@amd.com>

Tom,

On Thu, 8 Aug 2019, Lendacky, Thomas wrote:
> On 8/8/19 3:36 PM, Thomas Gleixner wrote:
> > 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.
> 
> Yes, sort of. There are two ways to overclock and it all depends on which
> one was used. If the overclocking is done by changing the multipliers,
> then that 100MHz clock will still be 100MHz. But if the overclocking is
> done by increasing the input clock, then that 100MHz clock will also
> increase.
> 
> I was trying to get a bit more clarification on this before replying, but
> it can be detected in software. The base clock is 100MHz, so read the P0
> multiplier and the TSC should be counting at P0 * 100MHz. If you calibrate
> the speed of the TSC with the HPET you can see what speed the TSC is
> counting at. If you divide the TSC delta from the HPET calibration by the
> P0 multiplier you will either get 100MHz if there is no overclocking or if
> the multiplier method of overclocking was used, otherwise you'll get a
> higher value if the input clock method was used. Either way, that should
> give you the APIC clock speed based on a starting assumption of 100MHz.

The problem is that we have no HPET on those machines ....

I think I can get away without having HPET and PIT and do some smart stuff
with the pm timer for that stuff. I'll look at it tomorrow with brain
actually awake.

Thanks,

	tglx






  reply	other threads:[~2019-08-08 21:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01  6:24 setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms Daniel Drake
2019-08-01  7:16 ` Aubrey Li
2019-08-01  7:35   ` Thomas Gleixner
2019-08-01  7:56     ` Aubrey Li
2019-08-01  8:13       ` Thomas Gleixner
2019-08-01  8:21         ` Li, Aubrey
2019-08-01 10:13           ` Thomas Gleixner
2019-08-01 15:44             ` Lendacky, Thomas
2019-08-08 20:36               ` Thomas Gleixner
2019-08-08 21:01                 ` Lendacky, Thomas
2019-08-08 21:08                   ` Thomas Gleixner [this message]
2019-08-08 21:36                     ` Lendacky, Thomas
2019-08-09 12:54                       ` [PATCH] x86/apic: Handle missing global clockevent gracefully Thomas Gleixner
2019-08-09 12:59                         ` Jiri Slaby
2019-08-09 13:58                         ` Lendacky, Thomas
2019-08-09 19:40                           ` Thomas Gleixner
2019-08-12  6:16                         ` Daniel Drake
2019-08-12  7:03                           ` Jiri Slaby
2019-08-15  5:02                           ` Daniel Drake
2019-08-12  7:46                         ` Li, Aubrey
2019-08-12 12:24                           ` Thomas Gleixner
2019-08-12 12:59                             ` Aubrey Li
2019-08-12 17:11                               ` Thomas Gleixner
2019-08-19 10:37                         ` [tip:x86/urgent] " tip-bot for Thomas Gleixner
2019-08-01  9:00   ` setup_boot_APIC_clock() NULL dereference during early boot on reduced hardware platforms Daniel Drake
2019-08-01 10:17     ` Thomas Gleixner
2019-08-01  7:27 ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.1908082306220.2882@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=Thomas.Lendacky@amd.com \
    --cc=aubrey.intel@gmail.com \
    --cc=aubrey.li@linux.intel.com \
    --cc=drake@endlessm.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@endlessm.com \
    --cc=mingo@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).