Update support for the UV kernel to accommodate Intel BIOS changes in
NVDIMM alignment, which caused UV BIOS to align the memory boundaries
on different blocks than the previous UV standard of 2GB.
Background: Since 2009 the UV arch dependent support has used 2GB as the
memory block size mainly t
Add a new function to "adjust" the current fixed UV memory block size
of 2GB so it can be changed to a different physical boundary. This is
out of necessity so arch dependent code can accommodate specific BIOS
requirements which can align these new PMEM modules at less than the
default boundaries.
Add a call to the new function to "adjust" the current fixed UV memory
block size of 2GB so it can be changed to a different physical boundary.
This accommodates changes in the Intel BIOS, and therefore UV BIOS,
which now can align boundaries different than the previous UV standard
of 2GB. It also
Add a kernel parameter that allows setting UV memory block size. This
is to provide an adjustment for new forms of PMEM and other DIMM memory
that might require alignment restrictions other than scanning the global
address table for the required minimum alignment. The value set will be
further ad
Add a kernel parameter that allows setting UV memory block size. This
is to provide an adjustment for new forms of PMEM and other DIMM memory
that might require alignment restrictions other than scanning the global
address table for the required minimum alignment. The value set will be
further ad
Add a call to the new function to "adjust" the current fixed UV memory
block size of 2GB so it can be changed to a different physical boundary.
This accommodates changes in the Intel BIOS, and therefore UV BIOS, which
now can align boundaries different than the previous UV standard of 2GB.
It also
Add a new function to "adjust" the current fixed UV memory block size of
2GB so it can be changed to a different physical boundary. This is out
of necessity so UV BIOS can accommodate Intel BIOS changes for NVDIMM's,
which can align these new PMEM modules at other than 2GB boundaries.
A "set orde
Update support for the UV kernel to accommodate Intel BIOS changes in
NVDIMM alignment, which caused UV BIOS to align the memory boundaries
on different blocks than the previous UV standard of 2GB.
--
Updates to UV4 fix patches.
--
A critical error was found testing the fixed UV4 HUB in that an MMR
address was found to be incorrect. This causes the virtual address
space for accessing the MMIOH1 region to be allocated with the
incorrect size.
Signed-off-by: Mike Travis
---
arch/x86/include/asm/uv/uv_mmrs.h |2 +-
1 fil
The latest UV platforms include the new ApachePass NVDIMMs into the
UV address space. This has introduced address ranges in the Global
Address Map Table that are less than the previous lowest range, which
was 2GB. Fix the address calculation so it accommodates address ranges
from bytes to exabyte
* Fix GAM Range Table address ranges less than 1GB.
--
Fix build problem:
>> WARNING: vmlinux.o(.text+0x4223a): Section mismatch in
reference from the function uv_tsc_check_sync() to the function
.init.text:uv_early_read_mmr() The function uv_tsc_check_sync()
references the function __init uv_early_read_mmr(). This is often
because uv_tsc
Insert a check early in UV system startup that checks whether BIOS was
able to obtain satisfactory TSC Sync stability. If not, it usually
is caused by an error in the external TSC clock generation source.
In this case the best fallback is to use the builtin hardware RTC
as the kernel will not be a
Add a flag to indicate and process that TSC counters are on chassis
that reset at different times during system startup. Therefore which
TSC ADJUST values should be zero is not predictable.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Russ Anderson
Reviewed-by: Andrew
On systems where multiple chassis are reset asynchronously, and thus
the TSC counters are started asynchronously, the offset needed to
convert to TSC to ART would be different. Disable ART in that case
and rely on the TSC counters to supply the accurate time.
Signed-off-by: Mike Travis
Reviewed-
Prior to the TSC ADJUST MSR being available, the method to set TSC's in
sync with each other naturally caused a small skew between cpu threads.
This was NOT a firmware bug at the time so introducing a whole avalanche
of alarming warning messages might cause unnecessary concern and customer
complain
[Patches merged against 4.14.0-rc4]
The UV BIOS goes to considerable effort to get the TSC synchronization
accurate across the entire system. Included in that are multiple chassis
that can have 32+ sockets. The architecture does support an external
high resolution clock to aid in maintaining th
If the TSC has already been determined to be unstable, then checking
TSC ADJUST values is a waste of time and generates unnecessary error
messages.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Russ Anderson
Reviewed-by: Peter Zijlstra
---
v2: Add check_tsc_unstable to
Insert a check early in UV system startup that checks whether BIOS was
able to obtain satisfactory TSC Sync stability. If not, it usually
is caused by an error in the external TSC clock generation source.
In this case the best fallback is to use the builtin hardware RTC
as the kernel will not be a
The UV BIOS goes to considerable effort to get the TSC synchronization
accurate across the entire system. Included in that are multiple chassis
that can have 32+ sockets. The architecture does support an external
high resolution clock to aid in maintaining this synchronization.
The resulting TS
Prior to the TSC ADJUST MSR being available, the method to set TSC's in
sync with each other naturally caused a small skew between cpu threads.
This was NOT a firmware bug at the time so introducing a whole avalanche
of alarming warning messages might cause unnecessary concern and customer
complain
If the TSC has already been determined to be unstable, then checking
TSC ADJUST values is a waste of time and generates unnecessary error
messages.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Russ Anderson
Reviewed-by: Peter Zijlstra
---
arch/x86/kernel/tsc_sync.c |
Add a flag to indicate and process that TSC counters are on chassis
that reset at different times during system startup. Therefore which
TSC ADJUST values should be zero is not predictable.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Russ Anderson
Reviewed-by: Andrew
On systems where multiple chassis are reset asynchronously, and thus
the TSC counters are started asynchronously, the offset needed to
convert to TSC to ART would be different. Disable ART in that case
and rely on the TSC counters to supply the accurate time.
Signed-off-by: Mike Travis
Reviewed-
Add a flag to indicate and process that TSC counters are on chassis
that reset at different times during system startup. Therefore which
TSC ADJUST values should be zero is not predictable.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Russ Anderson
Reviewed-by: And ew
The UV BIOS goes to considerable effort to get the TSC synchronization
accurate across the entire system. Included in that are multiple chassis
that can have 32+ sockets. The architecture does support an external
high resolution clock to aid in maintaining this synchronization.
The resulting TS
On systems where multiple chassis are reset asynchronously there is not a
constant ratio between the ART frequency and the TSC time that can be
provided by the boot cpu. Provide a means to disable the ART capability
by arches that have this characteristic.
Signed-off-by: Mike Travis
---
arch/x8
Insert a check early in UV system startup that checks whether BIOS was
able to obtain satisfactory TSC Sync stability. If not, it usually
is caused by an error in the external TSC clock generation source.
In this case the best fallback is to use the builtin hardware RTC
as the kernel will not be a
Prior to the TSC ADJUST MSR being available, the method to set TSC's in
sync with each other naturally caused a small skew between cpu threads.
This was NOT a firmware bug at the time so introducing a whole avalanche
of alarming warning messages might cause unnecessary concern and customer
complain
If the TSC has already been determined to be unstable, then checking
TSC ADJUST values is a waste of time and generates unnecessary error
messages.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Russ Anderson
Reviewed-by: Peter Zijlstra
---
arch/x86/kernel/tsc_sync.c |
If the TSC has already been determined to be unstable, then checking
TSC ADJUST values is a waste of time and generates unnecessary error
messages.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Russ Anderson
---
arch/x86/kernel/tsc_sync.c |8
1 file changed
The UV BIOS goes to considerable effort to get the TSC synchronization
accurate across the entire system. Included in that are multiple chassis
that can have 32+ sockets. The architecture does support an external
high resolution clock to aid in maintaining this synchronization.
The resulting TS
Prior to the TSC ADJUST MSR being available, the method to set TSC's in
sync with each other naturally caused a small skew between cpu threads.
This was NOT a firmware bug at the time so introducing a whole avalanche
of alarming warning messages might cause unnecessary concern and customer
complain
Insert a check early in UV system startup that checks whether BIOS was
able to obtain satisfactory TSC Sync stability. If not, it usually
is caused by an error in the external TSC clock generation source.
In this case the best fallback is to use the builtin hardware RTC
as the kernel will not be a
Remove the requirement that the TSC ADJUST value for socket 0 must
be zero. This is the case when there are multiple chassis are being
reset asynchronously with each other and socket 0 may not necessarily
be starting first.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: R
Insert a check early in UV system startup that checks whether BIOS was
able to obtain satisfactory TSC Sync stability. If not, it usually
is caused by an error in the external TSC clock generation source.
In this case the best fallback is to use the builtin hardware RTC as
the kernel would also no
The UV BIOS goes to considerable effort to get the TSC synchronization
accurate across the entire system. Included in that are multiple
chassis that can have 32+ sockets. The architecture also supports an
external high resolution clock to help all the chassis and CPU's in
maintaining this synchr
If the TSC has already been determined to be unstable, then checking
TSC ADJUST values is a waste of time and generates unnecessary error
messages (840 for a 16 socket Skylake 28/2 core/ht system).
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Russ Anderson
---
arch/x86
Add a flag to indicate that a TSC ADJUST value of non-zero is valid
on Socket 0. This is required on multiple chassis systems for which
the Time Stamp Counter on all the chassis are started asynchronously.
The UV architecture is an example of this.
In this scenario the UV system BIOS will adjust
40 matches
Mail list logo
