From: Yazen Ghannam
...now that the data is available earlier.
Signed-off-by: Yazen Ghannam
---
Link:
https://lkml.kernel.org/r/20191018153114.39378-5-yazen.ghan...@amd.com
v1 -> v2:
* No change.
rfc -> v1:
* No change.
drivers/edac/amd64_edac.c | 20
1 file changed, 8
From: Yazen Ghannam
The following commit introduced a warning on error reports without a
non-zero grain value.
3724ace582d9 ("EDAC/mc: Fix grain_bits calculation")
The amd64_edac_mod module does not provide a value, so the warning will
be given on the first reported memory error.
Set the
From: Yazen Ghannam
Return early before checking for ECC if the node does not have any
populated memory.
Free any cached hardware data before returning. Also, return 0 in this
case since this is not a failure. Other nodes may have memory and the
module should attempt to load an instance for
From: Yazen Ghannam
Split out gathering hardware information from init_one_instance() into a
separate function hw_info_get().
This is necessary so that the information can be cached earlier and used
to check if memory is populated and if ECC is enabled on a node.
Also, define a function
From: Yazen Ghannam
The maximum number of memory controllers is fixed within a family/model
group. In most cases, this has been fixed at 2, but some systems may
have up to 8.
The struct amd64_family_type already contains family/model-specific
information, and this can be used rather than adding
From: Yazen Ghannam
Hi Boris,
Most of these patches address the issue where the module checks and
complains about DRAM ECC on nodes without memory.
Thanks,
Yazen
Link:
https://lkml.kernel.org/r/20191018153114.39378-1-yazen.ghan...@amd.com
Yazen Ghannam (6):
EDAC/amd64: Make struct
From: Yazen Ghannam
The struct amd64_family_type doesn't change between multiple nodes and
instances of the modules, so make it global.
Signed-off-by: Yazen Ghannam
---
Link:
https://lkml.kernel.org/r/20191018153114.39378-2-yazen.ghan...@amd.com
v1 -> v2:
* No change.
rfc -> v1:
* New patch
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Borislav Petkov
> Sent: Monday, October 21, 2019 10:48 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 0/6] AMD64 EDAC: Ch
From: Yazen Ghannam
Hi Boris,
This set contains the next revision of the RFC patches I included with
the last AMD64 EDAC updates. I dropped the RFC tags, and I added a
couple of new patches.
Most of these patches address the issue where the module check and
complains about DRAM ECC on nodes
From: Yazen Ghannam
Return early before checking for ECC if the node does not have any
populated memory.
Free any cached hardware data before returning. Also, return 0 in this
case since this is not a failure. Other nodes may have memory and the
module should attempt to load an instance for
From: Yazen Ghannam
...now that the data is available earlier.
Signed-off-by: Yazen Ghannam
---
Link:
https://lkml.kernel.org/r/20190821235938.118710-10-yazen.ghan...@amd.com
rfc -> v1:
* No change.
drivers/edac/amd64_edac.c | 20
1 file changed, 8 insertions(+), 12
From: Yazen Ghannam
The struct amd64_family_type doesn't change between multiple nodes and
instances of the modules, so make it global.
Signed-off-by: Yazen Ghannam
---
Link:
https://lkml.kernel.org/r/20190821235938.118710-9-yazen.ghan...@amd.com
rfc -> v1:
* New patch based on suggestion
From: Yazen Ghannam
The following commit introduced a warning on error reports without a
non-zero grain value.
3724ace582d9 ("EDAC/mc: Fix grain_bits calculation")
The amd64_edac_mod module does not provide a value, so the warning will
be given on the first reported memory error.
Set the
From: Yazen Ghannam
The maximum number of memory controllers is fixed within a family/model
group. In most cases, this has been fixed at 2, but some systems may
have up to 8.
The struct amd64_family_type already contains family/model-specific
information, and this can be used rather than adding
From: Yazen Ghannam
Split out gathering hardware information from init_one_instance() into a
separate function get_hardware_info().
This is necessary so that the information can be cached earlier and used
to check if memory is populated and if ECC is enabled on a node.
Signed-off-by: Yazen
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, September 6, 2019 3:35 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH v3 08/10] EDAC/a
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Borislav Petkov
> Sent: Thursday, August 29, 2019 4:23 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH v3 08/10] EDAC/a
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Monday, August 26, 2019 9:59 AM
> To: Ghannam, Yazen
> Cc: Adam Borowski ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, August 23, 2019 10:38 AM
> To: Ghannam, Yazen
> Cc: Adam Borowski ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Ghannam, Yazen
> Sent: Thursday, August 22, 2019 1:54 PM
> To: Adam Borowski
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; b...@alien8.de
> Subject: RE: [PATCH v3
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, August 23, 2019 6:26 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3 7/8] EDAC/amd64: Support
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Adam Borowski
> Sent: Wednesday, August 21, 2019 7:50 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; b...@alien8.de
> Subject: Re: [PATCH v3
From: Yazen Ghannam
Return early before checking for ECC if the node does not have any
populated memory.
Free any cached hardware data before returning. Also, return 0 in this
case since this is not a failure. Other nodes may have memory and the
module should attempt to load an instance for
From: Yazen Ghannam
Return early before checking for ECC if the node does not have any
populated memory.
Free any cached hardware data before returning. Also, return 0 in this
case since this is not a failure. Other nodes may have memory and the
module should attempt to load an instance for
From: Yazen Ghannam
Future AMD systems will support "Asymmetric" Dual-Rank DIMMs. These are
DIMMs where the ranks are of different sizes.
The even rank will use the Primary Even Chip Select registers and the
odd rank will use the Secondary Odd Chip Select registers.
Recognize if a Secondary
From: Yazen Ghannam
AMD Family 17h systems support x4 and x16 DRAM devices. However, the
device type is not checked when setting EDAC_CTL_CAP.
Set the appropriate EDAC_CTL_CAP flag based on the device type.
Default to x8 DRAM device when neither the x4 or x16 bits are set.
Fixes: 2d09d8f301f5
From: Yazen Ghannam
Currently, the DIMM info for AMD Family 17h systems is initialized in
init_csrows(). This function is shared with legacy systems, and it has a
limit of two channel support.
This prevents initialization of the DIMM info for a number of ranks, so
there will be missing ranks in
From: Yazen Ghannam
...now that the data is available earlier.
Signed-off-by: Yazen Ghannam
---
drivers/edac/amd64_edac.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index
From: Yazen Ghannam
Split out gathering hardware information from init_one_instance() into a
separate function get_hardware_info().
This is necessary so that the information can be cached earlier and used
to check if memory is populated and if ECC is enabled on a node.
Signed-off-by: Yazen
From: Yazen Ghannam
Return early before checking for ECC if the node does not have any
populated memory.
Free any cached hardware data before returning. Also, return 0 in this
case since this is not a failure. Other nodes may have memory and the
module should attempt to load an instance for
From: Yazen Ghannam
AMD Family 17h systems currently require address translation in order to
report the system address of a DRAM ECC error. This is currently done
before decoding the syndrome information. The syndrome information does
not depend on the address translation, so the proper EDAC
From: Yazen Ghannam
Chip Select memory size reporting on AMD Family 17h was recently fixed
in order to account for interleaving. However, the current method is not
robust.
The Chip Select Address Mask can be used to find the memory size. There
are a couple of cases.
1) For single-rank and
From: Yazen Ghannam
Hi Boris,
This set contains a few fixes for some changes merged in v5.2. There
are also a couple of fixes for older issues. In addition, there are a
couple of patches to add support for Asymmetric Dual-Rank DIMMs.
I don't have the failing config readily available that you
From: Yazen Ghannam
The struct chip_select array that's used for saving chip select bases
and masks is fixed at length of two. There should be one struct
chip_select for each controller, so this array should be increased to
support systems that may have more than two controllers.
Increase the
From: Yazen Ghannam
AMD Family 17h systems have a set of secondary Chip Select Base
Addresses and Address Masks. These do not represent unique Chip
Selects, rather they are used in conjunction with the primary
Chip Select registers in certain use cases.
Cache these secondary Chip Select
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, August 2, 2019 2:42 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 2/7] EDAC/amd64: Recog
> -Original Message-
> From: Borislav Petkov
> Sent: Friday, August 2, 2019 1:50 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 1/7] EDAC/amd64: Support more than two controllers for
> chip selects
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, August 2, 2019 9:46 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 0/7] AMD64 EDAC
esh Kumar
> ; Robert Moore
> ; Erik Schmauss ; Ghannam,
> Yazen
> Subject: Re: [PATCHv3 0/6] CPPC optional registers AMD support
>
> On Wed, Jul 10, 2019 at 06:37:09PM +, Natarajan, Janakarajan wrote:
> > CPPC (Collaborative Processor Performance Control) offers opt
From: Yazen Ghannam
AMD Family 17h systems currently require address translation in order to
report the system address of a DRAM ECC error. This is currently done
before decoding the syndrome information. The syndrome information does
not depend on the address translation, so the proper EDAC
From: Yazen Ghannam
AMD Family 17h systems have a set of secondary Chip Select Base
Addresses and Address Masks. These do not represent unique Chip
Selects, rather they are used in conjunction with the primary
Chip Select registers in certain use cases.
Cache these secondary Chip Select
From: Yazen Ghannam
The struct chip_select array that's used for saving chip select bases
and masks is fixed at length of two. There should be one struct
chip_select for each controller, so this array should be increased to
support systems that may have more than two controllers.
Increase the
From: Yazen Ghannam
Future AMD systems will support "Asymmetric" Dual-Rank DIMMs. These are
DIMMs were the ranks are of different sizes.
The even rank will use the Primary Even Chip Select registers and the
odd rank will use the Secondary Odd Chip Select registers.
Recognize if a Secondary Odd
From: Yazen Ghannam
Chip Select memory size reporting on AMD Family 17h was recently fixed
in order to account for interleaving. However, the current method is not
robust.
The Chip Select Address Mask can be used to find the memory size. There
are a few cases.
1) For single-rank, use the
From: Yazen Ghannam
AMD Family 17h systems support x4 and x16 DRAM devices. However, the
device type is not checked when setting EDAC_CTL_CAP.
Set the appropriate EDAC_CTL_CAP flag based on the device type.
Fixes: 2d09d8f301f5 ("EDAC, amd64: Determine EDAC MC capabilities on Fam17h")
From: Yazen Ghannam
Currently, the DIMM info for AMD Family 17h systems is initialized in
init_csrows(). This function is shared with legacy systems, and it has a
limit of two channel support.
This prevents initialization of the DIMM info for a number of ranks, so
there will be missing ranks in
From: Yazen Ghannam
Hi Boris,
This set contains a few fixes for some changes merged in v5.2. There
are also a couple of fixes for older issues. In addition, there are a
couple of patches to add support for Asymmetric Dual-Rank DIMMs.
Thanks,
Yazen
Link:
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Borislav Petkov
> Sent: Thursday, June 13, 2019 5:23 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/8] EDAC/amd64:
> -Original Message-
> From: Borislav Petkov
> Sent: Thursday, June 13, 2019 8:58 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/8] EDAC/amd64: Fix number of DIMMs and Chip Select
> bases/masks on Famil
> -Original Message-
> From: Borislav Petkov
> Sent: Thursday, June 13, 2019 9:17 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/8] EDAC/amd64: Support more than two controllers for
> chip selects hand
From: Yazen Ghannam
The OS is expected to write all bits to MCA_CTL for each bank,
thus enabling error reporting in all banks. However, some banks
may be unused in which case the registers for such banks are
Read-as-Zero/Writes-Ignored. Also, the OS may avoid setting some control
bits because of
From: Yazen Ghannam
On legacy systems, the addresses of the MCA_MISC* registers need to be
recursively discovered based on a Block Pointer field in the registers.
On Scalable MCA systems, the register space is fixed, and particular
addresses can be derived by regular offsets for bank and
From: Yazen Ghannam
The struct mce_banks[] array is only used in mce/core.c so move its
definition there and make it static. Also, change the "init" field to
bool type.
Signed-off-by: Yazen Ghannam
---
Link:
https://lkml.kernel.org/r/20190430203206.104163-2-yazen.ghan...@amd.com
v3->v4:
* No
From: Yazen Ghannam
The number of MCA banks is provided per logical CPU. Historically, this
number has been the same across all CPUs, but this is not an
architectural guarantee. Future AMD systems may have MCA bank counts
that vary between logical CPUs in a system.
This issue was partially
From: Yazen Ghannam
Current AMD systems have unique MCA banks per logical CPU even though
the type of the banks may all align to the same bank number. Each CPU
will have control of a set of MCA banks in the hardware and these are
not shared with other CPUs.
For example, bank 0 may be the
From: Yazen Ghannam
The focus of this patchset is define and use the MCA bank structures
and bank count per logical CPU.
With the exception of patch 4, this set applies to systems in production
today.
Patch 1:
Moves the declaration of struct mce_banks[] to the only file it's used.
Patch 2:
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, June 7, 2019 11:59 AM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, June 7, 2019 11:37 AM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
> -Original Message-
> From: Ghannam, Yazen
> Sent: Tuesday, April 23, 2019 12:53 PM
> To: Ghannam, Yazen ; linux...@vger.kernel.org;
> len.br...@intel.com
> Cc: linux-kernel@vger.kernel.org; Len Brown
> Subject: RE: [PATCH] tools/power turbostat: Make interval calc
> -Original Message-
> From: Borislav Petkov
> Sent: Monday, May 27, 2019 6:29 PM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re: [PATCH v3 5/6] x86/MCE: Save MCA control bits that g
From: Yazen Ghannam
AMD Family 17h systems currently require address translation in order to
report the system address of a DRAM ECC error. This is currently done
before decoding the syndrome information. The syndrome information does
not depend on the address translation, so the proper EDAC
From: Yazen Ghannam
AMD Family 17h systems support x4 and x16 DRAM devices. However, the
device type is not checked when setting EDAC_CTL_CAP.
Set the appropriate EDAC_CTL_CAP flag based on the device type.
Fixes: 2d09d8f301f5 ("EDAC, amd64: Determine EDAC MC capabilities on Fam17h")
From: Yazen Ghannam
AMD Family 17h systems have a set of secondary Chip Select Base
Addresses and Address Masks. These do not represent unique Chip
Selects, rather they are used in conjunction with the primary
Chip Select registers in certain use cases.
Cache these secondary Chip Select
From: Yazen Ghannam
The struct chip_select array that's used for saving chip select bases
and masks is fixed at length of two. There should be one struct
chip_select for each controller, so this array should be increased to
support systems that may have more than two controllers.
Increase the
From: Yazen Ghannam
Future AMD systems will support "Asymmetric" Dual-Rank DIMMs. These are
DIMMs were the ranks are of different sizes.
The even rank will use the Primary Even Chip Select registers and the
odd rank will use the Secondary Odd Chip Select registers.
Recognize if a Secondary Odd
From: Yazen Ghannam
Currently, the DIMM info for AMD Family 17h systems is initialized in
init_csrows(). This function is shared with legacy systems, and it has a
limit of two channel support.
This prevents initialization of the DIMM info for a number of ranks, so
there will be missing ranks in
From: Yazen Ghannam
Chip Select memory size reporting on AMD Family 17h was recently fixed
in order to account for interleaving. However, the current method is not
robust.
The Chip Select Address Mask can be used to find the memory size. There
are a few cases.
1) For single-rank, use the
From: Yazen Ghannam
...because AMD Family 17h systems support 2 DIMMs, 4 CS bases, and 2 CS
masks per channel.
Fixes: 07ed82ef93d6 ("EDAC, amd64: Add Fam17h debug output")
Signed-off-by: Yazen Ghannam
---
drivers/edac/amd64_edac.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
From: Yazen Ghannam
Hi Boris,
This set contains a few fixes for some changes merged in v5.2. There
are also a couple of fixes for older issues. In addition, there are a
couple of patches to add support for Asymmetric Dual-Rank DIMMs.
Thanks,
Yazen
Yazen Ghannam (8):
EDAC/amd64: Fix number
> -Original Message-
> From: Borislav Petkov
> Sent: Friday, May 17, 2019 3:02 PM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re: [PATCH v3 5/6] x86/MCE: Save MCA control bits that g
> -Original Message-
> From: Borislav Petkov
> Sent: Thursday, May 23, 2019 3:28 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org
> Subject: Re: [PATCH] x86/MCE: Statically all
From: Yazen Ghannam
The MCE control data is stored in an array of struct mce_banks. This
array has historically been shared by all CPUs and it was allocated
dynamically during the first CPU's init sequence.
However, starting with
5b0883f5c7be ("x86/MCE: Make mce_banks a per-CPU array")
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Tuesday, May 21, 2019 6:09 PM
> To: Luck, Tony
> Cc: Ghannam, Yazen ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
> -Original Message-
> From: Borislav Petkov
> Sent: Saturday, May 18, 2019 6:26 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; b...@suse.de;
> tony.l...@intel.com; x...@kernel.org
> Subject: Re: [PATCH v3 4/6] x86/MCE: Mak
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, May 17, 2019 2:35 PM
> To: Luck, Tony
> Cc: Ghannam, Yazen ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, May 17, 2019 5:10 AM
> To: Luck, Tony
> Cc: Ghannam, Yazen ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Thursday, May 16, 2019 12:21 PM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Thursday, May 16, 2019 11:57 AM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
> -Original Message-
> From: Luck, Tony
> Sent: Thursday, May 16, 2019 10:52 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; b...@suse.de;
> x...@kernel.org
> Subject: Re: [PATCH v3 5/6] x86/MCE: Save MCA control bits that g
From: Yazen Ghannam
The struct mce_banks[] array is only used in mce/core.c so move the
definition of struct mce_bank to mce/core.c and make the array static.
Also, change the "init" field to bool type.
Signed-off-by: Yazen Ghannam
---
Link:
From: Yazen Ghannam
The OS is expected to write all bits in MCA_CTL. However, only
implemented bits get set in the hardware.
Read back MCA_CTL so that the value in the hardware is saved and
reported through sysfs.
Signed-off-by: Yazen Ghannam
---
Link:
From: Yazen Ghannam
The OS is expected to write all bits to MCA_CTL for each bank. However,
some banks may be unused in which case the registers for such banks are
Read-as-Zero/Writes-Ignored. Also, the OS may not write any control bits
because of quirks, etc.
A bank can be considered
From: Yazen Ghannam
The focus of this patchset is define and use the MCA bank structures
and bank count per logical CPU.
With the exception of patch 4, this set applies to systems in production
today.
Patch 1:
Moves the declaration of struct mce_banks[] to the only file it's used.
Patch 2:
From: Yazen Ghannam
The number of MCA banks is provided per logical CPU. Historically, this
number has been the same across all CPUs, but this is not an
architectural guarantee. Future AMD systems may have MCA bank counts
that vary between logical CPUs in a system.
This issue was partially
From: Yazen Ghannam
Current AMD systems have unique MCA banks per logical CPU even though
the type of the banks may all align to the same bank number. Each CPU
will have control of a set of MCA banks in the hardware and these are
not shared with other CPUs.
For example, bank 0 may be the
From: Yazen Ghannam
On legacy systems, the addresses of the MCA_MISC* registers need to be
recursively discovered based on a Block Pointer field in the registers.
On Scalable MCA systems, the register space is fixed, and particular
addresses can be derived by regular offsets for bank and
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Ghannam, Yazen
> Sent: Monday, March 25, 2019 12:33 PM
> To: linux...@vger.kernel.org
> Cc: Ghannam, Yazen ; linux-kernel@vger.kernel.org;
> l...@kernel.org
> Subject: [PATCH] too
> -Original Message-
> From: Rafael J. Wysocki
> Sent: Wednesday, April 17, 2019 5:11 PM
> To: Ghannam, Yazen
> Cc: Rafael J. Wysocki ; Natarajan, Janakarajan
> ; linux-a...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux...@vger.kernel.org; de...
J . Wysocki
> ; Len Brown ; Viresh Kumar
> ; Robert Moore ; Erik
> Schmauss ; Ghannam, Yazen
>
> Subject: Re: [PATCH v2 0/7] CPPC optional registers AMD support
>
> On Tue, Apr 16, 2019 at 12:35 AM Janakarajan Natarajan
> wrote:
> >
> > On 4/4/19 4:25 PM
From: Yazen Ghannam
The focus of this patchset is define and use the MCA bank structures
and bank count per logical CPU.
With the exception of patch 4, this set applies to systems in production
today.
Patch 1:
Moves the declaration of struct mce_banks[] to the only file it's used.
Patch 2:
From: Yazen Ghannam
On legacy systems, the addresses of the MCA_MISC* registers need to be
recursively discovered based on a Block Pointer field in the registers.
On Scalable MCA systems, the register space is fixed, and particular
addresses can be derived by regular offsets for bank and
From: Yazen Ghannam
The struct mce_banks[] array is only used in mce/core.c so move the
definition of struct mce_bank to mce/core.c and make the array static.
Also, change the "init" field to bool type.
Signed-off-by: Yazen Ghannam
---
Link:
From: Yazen Ghannam
Current AMD systems have unique MCA banks per logical CPU even though
the type of the banks may all align to the same bank number. Each CPU
will have control of a set of MCA banks in the hardware and these are
not shared with other CPUs.
For example, bank 0 may be the
From: Yazen Ghannam
The number of MCA banks is provided per logical CPU. Historically, this
number has been the same across all CPUs, but this is not an
architectural guarantee. Future AMD systems may have MCA bank counts
that vary between logical CPUs in a system.
This issue was partially
From: Yazen Ghannam
The OS is expected to write all bits in MCA_CTL. However, only
implemented bits get set in the hardware.
Read back MCA_CTL so that the value in the hardware is saved and
reported through sysfs.
Signed-off-by: Yazen Ghannam
---
Link:
From: Yazen Ghannam
The OS is expected to write all bits to MCA_CTL for each bank. However,
some banks may be unused in which case the registers for such banks are
Read-as-Zero/Writes-Ignored. Also, the OS may not write any control bits
because of quirks, etc.
A bank can be considered
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Wednesday, April 10, 2019 12:26 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org
> -Original Message-
> From: Borislav Petkov
> Sent: Wednesday, April 10, 2019 11:41 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org
> Subject: Re: [PATCH RESEND 2/5] x86/MCE: Handle MCA
> -Original Message-
> From: Borislav Petkov
> Sent: Tuesday, April 9, 2019 3:34 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org
> Subject: Re: [PATCH RESEND 2/5] x86/MCE: Handle MCA cont
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Luck, Tony
> Sent: Monday, April 8, 2019 6:23 PM
> To: Ghannam, Yazen
> Cc: Borislav Petkov ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
1 - 100 of 361 matches
Mail list logo
