}
/*
* Run 5 calibration loops to get the lowest frequency value
---
From: patrickg
Sent: Thursday, October 25, 2018 12:13 PM
To: Prarit Bhargava; Brown, Len; linux-kernel@vger.kernel.org
Cc: mi...@kernel.org; Du, Alek; ar...@l
}
/*
* Run 5 calibration loops to get the lowest frequency value
---
From: patrickg
Sent: Thursday, October 25, 2018 12:13 PM
To: Prarit Bhargava; Brown, Len; linux-kernel@vger.kernel.org
Cc: mi...@kernel.org; Du, Alek; ar...@l
Sorry for the delay; lkml folder sorting gone wrong.
On 10/25/18 11:01 AM, Prarit Bhargava wrote:
> Patrick can you reply back with the entire patch
Yes; watch the editor bork it even more than it originally did, though.
---Copypasta of first RFC patch---
---
diff --git
Sorry for the delay; lkml folder sorting gone wrong.
On 10/25/18 11:01 AM, Prarit Bhargava wrote:
> Patrick can you reply back with the entire patch
Yes; watch the editor bork it even more than it originally did, though.
---Copypasta of first RFC patch---
---
diff --git
On 10/25/2018 01:12 PM, patrickg wrote:
> Resurrecting w/ +prarit who was handling mentions in a RHEL bug report
> regarding this.
>
Patrick can you reply back with the entire patch?
Thanks,
P.
On 10/25/2018 01:12 PM, patrickg wrote:
> Resurrecting w/ +prarit who was handling mentions in a RHEL bug report
> regarding this.
>
Patrick can you reply back with the entire patch?
Thanks,
P.
Resurrecting w/ +prarit who was handling mentions in a RHEL bug report
regarding this.
Resurrecting w/ +prarit who was handling mentions in a RHEL bug report
regarding this.
So it's been pretty quiet here... anything? Even just to call me nuts or
explicitly state that the hardware is doing something totally wrong?
So it's been pretty quiet here... anything? Even just to call me nuts or
explicitly state that the hardware is doing something totally wrong?
tsc_khz still zero with production CPU's, so it's reassigning tsc_khz to the
cpuid-acquired cpu_khz value.
tsc_khz still zero with production CPU's, so it's reassigning tsc_khz to the
cpuid-acquired cpu_khz value.
K, did significant poking.
native_calibrate_cpu is getting precidence no matter what because on SKL
server, native_calibrate_tsc is always returning zero (Note that there is a
caveat 2 lines down).
In native_calibrate_tsc, I'm seeing it always return zero after the `switch
K, did significant poking.
native_calibrate_cpu is getting precidence no matter what because on SKL
server, native_calibrate_tsc is always returning zero (Note that there is a
caveat 2 lines down).
In native_calibrate_tsc, I'm seeing it always return zero after the `switch
Sorry for the delay. Expect another large delay if you have any questions.
I'm pretty heavily context switching.
I wanted to double check to make sure that I wasn't mis-documenting and
mis-remembering things.
On 07/13/2018 07:40 PM, Brown, Len wrote:
> We disabled CPUID-based TSC calibration
Sorry for the delay. Expect another large delay if you have any questions.
I'm pretty heavily context switching.
I wanted to double check to make sure that I wasn't mis-documenting and
mis-remembering things.
On 07/13/2018 07:40 PM, Brown, Len wrote:
> We disabled CPUID-based TSC calibration
We disabled CPUID-based TSC calibration on SKX in December for several reasons.
If you still have it enabled, you need this patch:
commit b511203093489eb1829cb4de86e8214752205ac6
x86/tsc: Fix erroneous TSC rate on Skylake Xeon
If you are referring to another platform that has CPUID-TSC
We disabled CPUID-based TSC calibration on SKX in December for several reasons.
If you still have it enabled, you need this patch:
commit b511203093489eb1829cb4de86e8214752205ac6
x86/tsc: Fix erroneous TSC rate on Skylake Xeon
If you are referring to another platform that has CPUID-TSC
On 07/13/2018 12:40 PM, Arjan van de Ven wrote:
> On 7/13/2018 12:19 PM, patrickg wrote:
>> This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT
>> calibration methods should the user desire to.
>>
>> The current ordering in ML x86 tsc is to calibrate in the order listed
>>
On 07/13/2018 12:40 PM, Arjan van de Ven wrote:
> On 7/13/2018 12:19 PM, patrickg wrote:
>> This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT
>> calibration methods should the user desire to.
>>
>> The current ordering in ML x86 tsc is to calibrate in the order listed
>>
On 07/13/2018 12:40 PM, Arjan van de Ven wrote:
> On 7/13/2018 12:19 PM, patrickg wrote:
>> This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT
>> calibration methods should the user desire to.
>>
>> The current ordering in ML x86 tsc is to calibrate in the order listed
>>
On 07/13/2018 12:40 PM, Arjan van de Ven wrote:
> On 7/13/2018 12:19 PM, patrickg wrote:
>> This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT
>> calibration methods should the user desire to.
>>
>> The current ordering in ML x86 tsc is to calibrate in the order listed
>>
This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT calibration
methods should the user desire to.
The current ordering in ML x86 tsc is to calibrate in the order listed above;
returning whenever there's a successful calibration. However there are certain
BIOS/HW Designs for
This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT calibration
methods should the user desire to.
The current ordering in ML x86 tsc is to calibrate in the order listed above;
returning whenever there's a successful calibration. However there are certain
BIOS/HW Designs for
On 7/13/2018 12:19 PM, patrickg wrote:
This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT calibration
methods should the user desire to.
The current ordering in ML x86 tsc is to calibrate in the order listed above;
returning whenever there's a successful calibration. However
On 7/13/2018 12:19 PM, patrickg wrote:
This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT calibration
methods should the user desire to.
The current ordering in ML x86 tsc is to calibrate in the order listed above;
returning whenever there's a successful calibration. However
26 matches
Mail list logo
