linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>
To: Thomas Gleixner <tglx@linutronix.de>
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 21:01:51 +0000	[thread overview]
Message-ID: <5bf28ba4-b7c1-51de-88ae-feebae2a28db@amd.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1908082235590.2882@nanos.tec.linutronix.de>

Hi Thomas,

On 8/8/19 3:36 PM, Thomas Gleixner wrote:
> 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.

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.

I'm not all that familiar with this stuff, but I think I translated what
was told to me properly. I'm also not sure if this method can be used at
the point in the code this is all happening. Let me know if it makes sense
or not.

Thanks,
Tom

> 
> Thanks,
> 
> 	tglx
> 

  reply	other threads:[~2019-08-08 21:01 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 [this message]
2019-08-08 21:08                   ` Thomas Gleixner
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=5bf28ba4-b7c1-51de-88ae-feebae2a28db@amd.com \
    --to=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=tglx@linutronix.de \
    --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).