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
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
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 ca
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 ca
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 ca
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 ca
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
Patch implements channel interleave hash if MCChanHashEn is set in HA on
Haswell/Broadwell. If this bit was set, but no math was used to
calculate the correct interleave index, sb_edac would place errors on
incorrect channels.
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
Patch implements channel interleave hash if MCChanHashEn is set in HA on
Haswell/Broadwell. If this bit was set, but no math was used to
calculate the correct interleave index, sb_edac would place errors on
incorrect channels.
diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
20 matches
Mail list logo
