>
> > The Socket ID is ApicId[bits] on Fam17h systems.
> >
> > Change substraction to logical AND when extracting socket_id
> > from c->apicid.
>
> So Fam17h will only ever have 2 sockets, right?
>
This is the decoding of the ApicId shown in our latest Programming
Reference. However, I can remo
> I asked the obvious question whether Fam17h will only ever have two
> sockets,
> because your patch limits it hard to that.
>
I don't know if Fam17h will only ever have two sockets, so I'll send a V2
removing the hard limit.
Thanks,
Yazen
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Monday, June 19, 2017 12:49 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; Tony Luck ;
> x...@kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] x86/mce: Al
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Sunday, May 28, 2017 1:22 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; Borislav Petkov ; Tony Luck
> ; x...@kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/3]
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Tuesday, May 30, 2017 9:57 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; Tony Luck ;
> x...@kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/3] x86/mce/AMD: D
> -Original Message-
> From: Borislav Petkov
> Sent: Thursday, August 9, 2018 11:16 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 1/2] x86/MCE/AMD: Check
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org
> On Behalf Of Borislav Petkov
> Sent: Thursday, August 9, 2018 11:18 AM
> 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: Tuesday, August 21, 2018 8:16 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 2/2] x86/MCE/AMD: Skip creati
> -Original Message-
> From: Michael Jin
> Sent: Thursday, August 16, 2018 2:29 PM
> To: Borislav Petkov ; Ghannam, Yazen
> ; Mauro Carvalho Chehab
>
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Michael Jin
> ; sta...@vger.kernel.org
> Subj
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org
> On Behalf Of Borislav Petkov
> Sent: Thursday, August 23, 2018 7:24 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org
>
> -Original Message-
> From: Luck, Tony
> Sent: Friday, July 27, 2018 5:09 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; b...@suse.de;
> x...@kernel.org
> Subject: Re: [PATCH] x86/mce: Handle varying MCA bank counts
>
&
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Lyude Paul
> Sent: Wednesday, January 24, 2018 12:49 PM
> To: Thomas Gleixner
> Cc: h...@zytor.com; keith.bu...@intel.com; mi...@kernel.org; linux-
> ker...@vger.kern
> -Original Message-
> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of
> Rafael J. Wysocki
> Sent: Thursday, January 11, 2018 12:39 PM
> To: Ghannam, Yazen
> Cc: ACPI Devel Maling List ; Linux Kernel Mailing
> List ; Linux PCI ;
> Rafael J. Wys
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Borislav Petkov
> Sent: Monday, March 26, 2018 3:31 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Borislav Petkov
> Sent: Monday, March 26, 2018 3:35 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...
> -Original Message-
> From: Borislav Petkov
> Sent: Monday, March 26, 2018 4:08 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 1/2] Revert "x86/mce/AMD:
> -Original Message-
> From: Luck, Tony
> Sent: Monday, March 26, 2018 4:28 PM
> To: Borislav Petkov
> Cc: Ghannam, Yazen ; linux-
> e...@vger.kernel.org; linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re: [PATCH 2/2] x86/MCE: Always save MCA_{ADDR,
> -Original Message-
> From: Borislav Petkov
> Sent: Thursday, March 1, 2018 7:00 AM
> To: Ghannam, Yazen
> Cc: Tony Luck ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; ard.biesheu...@linaro.org; x...@kernel.org
> Subject: Re: [PATCH v2 0/8] Decode
From: Yazen Ghannam
ACPI 6.2 includes a new definition for a Deferred Machine Check "DMC"
subtable.
The definition of this subtable was included in following commit:
c042933df2b1 ("ACPICA: Add support for new HEST subtable")
However, the HEST parsing function was not updated to include this ne
> -Original Message-
> From: Borislav Petkov
> Sent: Thursday, June 28, 2018 1:38 PM
> To: KVM
> Cc: Joerg Roedel ; Radim Krčmář ;
> Lendacky, Thomas ; Tony Luck
> ; Ghannam, Yazen ; LKML
>
> Subject: [PATCH 0/2] x86/kvm: Enable MCE injection in the guest v2
> -Original Message-
> From: Borislav Petkov
> Sent: Thursday, May 17, 2018 6:41 AM
> To: Johannes Hirte
> Cc: Ghannam, Yazen ; linux-
> e...@vger.kernel.org; linux-kernel@vger.kernel.org; tony.l...@intel.com;
> x...@kernel.org
> Subject: Re: [PATCH 3/3] x86/M
> -Original Message-
> From: Borislav Petkov
> Sent: Thursday, May 17, 2018 9:44 AM
> To: Ghannam, Yazen
> Cc: Johannes Hirte ; linux-
> e...@vger.kernel.org; linux-kernel@vger.kernel.org; tony.l...@intel.com;
> x...@kernel.org
> Subject: Re: [PATCH 3/3] x86/M
> -Original Message-
> From: Michael Jin
> Sent: Friday, August 10, 2018 2:36 PM
> To: Borislav Petkov ; Ghannam, Yazen
> ; Mauro Carvalho Chehab
>
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Michael Jin
>
> Subject: [PATCH] EDAC, amd6
> -Original Message-
> From: Michael Jin
> Sent: Wednesday, August 15, 2018 6:41 AM
> To: Borislav Petkov ; Ghannam, Yazen
> ; Mauro Carvalho Chehab
>
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Michael Jin
> ; sta...@vger.kernel.org
> Subj
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org
> On Behalf Of Borislav Petkov
> Sent: Wednesday, August 15, 2018 10:55 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org
>
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org
> On Behalf Of Ghannam, Yazen
> Sent: Thursday, August 9, 2018 1:18 PM
> To: Borislav Petkov
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org
> Subj
> -Original Message-
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Wednesday, February 28, 2018 3:43 AM
> To: Ghannam, Yazen ; Tony Luck
>
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ard.biesheu...@linaro.org; x...@kernel.org
> Su
> -Original Message-
> From: Borislav Petkov [mailto:b...@suse.de]
> Sent: Wednesday, February 28, 2018 11:36 AM
> To: Ghannam, Yazen
> Cc: Tony Luck ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; ard.biesheu...@linaro.org; x...@kernel.org
> Subje
> -Original Message-
> From: Ingo Molnar On Behalf Of Ingo Molnar
> Sent: Tuesday, April 3, 2018 7:04 AM
> To: Ghannam, Yazen
> Cc: x...@kernel.org; linux-kernel@vger.kernel.org; b...@suse.de
> Subject: Re: [PATCH] x86/smpboot: Don't do mwait_play_dead() on AMD
&g
> -Original Message-
> From: Ingo Molnar On Behalf Of Ingo Molnar
> Sent: Tuesday, April 3, 2018 10:41 AM
> To: Ghannam, Yazen
> Cc: x...@kernel.org; linux-kernel@vger.kernel.org; b...@suse.de
> Subject: Re: [PATCH] x86/smpboot: Don't do mwait_play_
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Ghannam, Yazen
> Sent: Tuesday, March 27, 2018 10:02 AM
> To: Borislav Petkov
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Borislav Petkov
> Sent: Wednesday, March 28, 2018 9:00 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/3]
> -Original Message-
> From: Borislav Petkov
> Sent: Wednesday, March 28, 2018 11:44 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/3] EDAC/amd64: Print ECC enabled/disabled for nodes
> with enabled MC
> -Original Message-
> From: Borislav Petkov
> Sent: Thursday, March 29, 2018 5:46 AM
> To: Ghannam, Yazen
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ard.biesheu...@linaro.org; x...@kernel.org; tony.l...@intel.com
> Subject: Re: [PATCH v3 2/8]
> -Original Message-
> From: Borislav Petkov
> Sent: Thursday, March 29, 2018 6:55 AM
> To: Ghannam, Yazen
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ard.biesheu...@linaro.org; x...@kernel.org; tony.l...@intel.com
> Subject: Re: [PATCH v3 3/8]
> -Original Message-
> From: Guenter Roeck On Behalf Of Guenter Roeck
> Sent: Sunday, April 29, 2018 2:24 PM
> To: Borislav Petkov ; Ghannam, Yazen
>
> Cc: Thomas Gleixner ; Clemens Ladisch
> ; x...@kernel.org; Jean Delvare ;
> linux-kernel@vger.kernel.org; lin
From: Yazen Ghannam
AMD systems may support Chip Select interleaving. However, on Family
17h+ this was not taken into account when printing the Chip Select
sizes.
Add support to detect if Chip Selects are interleaved on Family 17h+,
and adjust the sizes accordingly.
Signed-off-by: Yazen Ghannam
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 si
From: Yazen Ghannam
The first few models of Family 17h all had 2 Unified Memory Controllers
per Die, so this was treated as a fixed value. However, future systems
may have more Unified Memory Controllers per Die.
Related to this, the channel number and base address of a Unified Memory
Controller
From: Yazen Ghannam
Future AMD systems may support x16 symbol sizes.
Recognize if a system is using x16 symbol size. Also, simplify the print
statement.
Note that a x16 syndrome vector table is not necessary like with x4 or
x8. This is because systems that support x16 symbol sizes will be SMCA
From: Yazen Ghannam
Define and use a macro for looping over the number of Unified Memory
Controllers.
No functional change.
Signed-off-by: Yazen Ghannam
---
Link:
https://lkml.kernel.org/r/20190226172532.12924-3-yazen.ghan...@amd.com
v2->v3:
* Apply V2 Patch 3 before V2 Patch 2.
v1->v2:
* Ne
From: Yazen Ghannam
Add the new Family 17h Model 30h PCI IDs to the AMD64 EDAC module.
This also fixes a probe failure that appeared when some other PCI IDs
for Family 17h Model 30h were added to the AMD NB code.
Fixes: be3518a16ef2 (x86/amd_nb: Add PCI device IDs for family 17h, model 30h)
Sig
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
> -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...
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Ard Biesheuvel
> Sent: Saturday, February 2, 2019 3:41 AM
> To: linux-...@vger.kernel.org; Ingo Molnar ; Thomas
> Gleixner
> Cc: Ard Biesheuvel ; linux-kernel@vger.kernel.org;
> AKASHI Taka
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Tuesday, March 26, 2019 2:57 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> tony.l...@intel.com; x...@kernel.org; ra
> -Original Message-
> From: Borislav Petkov
> Sent: Tuesday, March 26, 2019 10:55 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] EDAC/amd64: Use maximum channel count for the EDAC
> channel layer siz
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 registe
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:
Spl
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
---
arch/x86/kernel/cpu/mce/core.c | 15 ++
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 addre
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 Load-St
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
---
arch/x86/kernel/cpu/mce/core.c | 11 ++-
arch
> -Original Message-
> From: Borislav Petkov
> Sent: Monday, April 8, 2019 12:52 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 Borislav Petkov
> Sent: Monday, April 8, 2019 3:50 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 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
> -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: 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: 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: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Tuesday, February 26, 2019 4:41 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/5] EDAC/amd64: Add
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Borislav Petkov
> Sent: Tuesday, February 26, 2019 5:07 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/5] EDAC/amd64: Suppo
From: Yazen Ghannam
AMD systems may support Chip Select interleaving. However, on Fam17h+
this was not taken into account when printing the Chip Select sizes.
Add support to detect if Chip Selects are interleaved on Fam17h+, and
adjust the sizes accordingly.
Signed-off-by: Yazen Ghannam
---
Li
From: Yazen Ghannam
Future AMD systems may support x16 symbol sizes.
Recognize if a system is using x16 symbol size. Also, simplify the print
statement.
Note that a x16 syndrome vector table is not necessary like with x4 or
x8. This is because systems that support x16 symbol sizes will be SMCA
From: Yazen Ghannam
The first few models of Family 17h all had 2 Unified Memory Controllers
per Die, so this was treated as a fixed value. However, future systems
may have more Unified Memory Controllers per Die.
Related to this, the channel number and base address of a Unified Memory
Controller
From: Yazen Ghannam
Add the new Family 17h Model 30h PCI IDs to the AMD64 EDAC module.
This also fixes a probe failure that appeared when some other PCI IDs
for Family 17h Model 30h were added to the AMD NB code.
Fixes: be3518a16ef2 (x86/amd_nb: Add PCI device IDs for family 17h, model 30h)
Sig
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 si
From: Yazen Ghannam
Define and use a macro for looping over the number of Unified Memory
Controllers.
No functional change.
Signed-off-by: Yazen Ghannam
---
Link:
https://lkml.kernel.org/r/20190219202536.15462-2-yazen.ghan...@amd.com
v1->v2:
* New in V2. Please see comment on Patch 2 V1 at li
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Tuesday, February 26, 2019 3:53 PM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 3/6] EDAC/amd64: Use
> -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: 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
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 register
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 si
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 csro
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 dual-
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 84832771dec0..c1cb0234
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 Ghan
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 them
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.
I don't have the failing config readily available that you us
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
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 Odd
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 them
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 them
> -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
> -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 fixe
> -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 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 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 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: 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 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
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 optiona
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 amd64_fam
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 b
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 hw_info
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
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 gra
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 them
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 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
1 - 100 of 265 matches
Mail list logo
