On 5/4/2015 1:46 PM, Borislav Petkov wrote:
For deferred errors, the workaround is a little different as it
applies to only the given family/model right now. If the workaround
needs to be applied for future processors, we can extend the family
check for those right?
Or, you can do the check for
On 5/3/2015 11:13 AM, Aravind Gopalakrishnan wrote:
On 5/1/15 7:42 PM, Aravind Gopalakrishnan wrote:
On 5/1/15 5:47 PM, Borislav Petkov wrote:
Aravind and I could probably test on a couple of AMD boxes to narrow
down.
@Aravind, see here:
https://lkml.kernel.org/r
On 5/1/15 7:42 PM, Aravind Gopalakrishnan wrote:
On 5/1/15 5:47 PM, Borislav Petkov wrote:
On Fri, May 01, 2015 at 02:42:39PM -0700, Len Brown wrote:
On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar wrote:
So instead of playing games with an ancient delay, I'd suggest we
install the 10 msec
On 5/1/15 7:42 PM, Aravind Gopalakrishnan wrote:
On 5/1/15 5:47 PM, Borislav Petkov wrote:
On Fri, May 01, 2015 at 02:42:39PM -0700, Len Brown wrote:
On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar mi...@kernel.org wrote:
So instead of playing games with an ancient delay, I'd suggest we
On 5/1/15 5:47 PM, Borislav Petkov wrote:
On Fri, May 01, 2015 at 02:42:39PM -0700, Len Brown wrote:
On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar wrote:
So instead of playing games with an ancient delay, I'd suggest we
install the 10 msec INIT assertion wait as a platform quirk instead,
On 5/1/2015 5:25 AM, Borislav Petkov wrote:
On Thu, Apr 30, 2015 at 09:49:22AM -0500, Aravind Gopalakrishnan wrote:
SUCCOR stands for S/W UnCorrectable error COntainment and Recovery.
It indicates support for data poisoning in HW and deferred error
interrupts.
struct mce_vendor_flags
On 5/1/2015 4:36 AM, Borislav Petkov wrote:
On Thu, Apr 30, 2015 at 11:16:30PM -0500, Aravind Gopalakrishnan wrote:
I used the term as it is an interrupt due to the deferred error.
Would 'deferred_err_interrupt' be more apt? Maybe 'irq_deferred_error_count'
for the counter?
Yeah, I think
On 5/1/2015 2:18 AM, Ingo Molnar wrote:
* Aravind Gopalakrishnan wrote:
Newer AMD processors can generate deferred errors and can be configured
to generate APIC interrupts on such events.
What's the wider context of this? What is it good for?
I suspect it's MCE related, but only from
On 5/1/15 5:47 PM, Borislav Petkov wrote:
On Fri, May 01, 2015 at 02:42:39PM -0700, Len Brown wrote:
On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar mi...@kernel.org wrote:
So instead of playing games with an ancient delay, I'd suggest we
install the 10 msec INIT assertion wait as a platform
On 5/1/2015 5:25 AM, Borislav Petkov wrote:
On Thu, Apr 30, 2015 at 09:49:22AM -0500, Aravind Gopalakrishnan wrote:
SUCCOR stands for S/W UnCorrectable error COntainment and Recovery.
It indicates support for data poisoning in HW and deferred error
interrupts.
struct mce_vendor_flags
On 5/1/2015 2:18 AM, Ingo Molnar wrote:
* Aravind Gopalakrishnan aravind.gopalakrish...@amd.com wrote:
Newer AMD processors can generate deferred errors and can be configured
to generate APIC interrupts on such events.
What's the wider context of this? What is it good for?
I suspect it's MCE
On 5/1/2015 4:36 AM, Borislav Petkov wrote:
On Thu, Apr 30, 2015 at 11:16:30PM -0500, Aravind Gopalakrishnan wrote:
I used the term as it is an interrupt due to the deferred error.
Would 'deferred_err_interrupt' be more apt? Maybe 'irq_deferred_error_count'
for the counter?
Yeah, I think
On 4/30/15 3:41 PM, Andy Lutomirski wrote:
On Thu, Apr 30, 2015 at 7:49 AM, Aravind Gopalakrishnan
wrote:
Changes introduced in the patch-
- Assign vector number 0xf4 for Deferred errors
- Declare deferred_interrupt, allocate gate and bind it
to DEFERRED_APIC_VECTOR.
- Declare
'setup_APIC_mce' doesn't give us an indication of why we are
going to program LVT. Make that explicit by renaming it to
setup_APIC_mce_threshold so we know.
No functional change is introduced.
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/kernel/cpu/mcheck/mce_amd.c | 4 ++--
1 file
Enforcing proper descending order of vector number assignments here.
No functional change.
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/include/asm/irq_vectors.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/irq_vectors.h
b/arch/x86
-off-by: Aravind Gopalakrishnan
---
arch/x86/include/asm/mce.h | 3 ++-
arch/x86/kernel/cpu/mcheck/mce.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 1f5a86d..dfcb664 100644
--- a/arch/x86/include/asm/mce.h
Deferred error interrupt stats on
/proc/interrupts by incrementing irq_deferred_count
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/include/asm/entry_arch.h| 3 +
arch/x86/include/asm/hardirq.h | 3 +
arch/x86/include/asm/hw_irq.h| 2 +
arch/x86/include/asm
are introduced.
Aravind Gopalakrishnan (4):
x86/mce: Define 'SUCCOR' cpuid bit
x86/mce/amd: Introduce deferred error interrupt handler
x86, irq: Cleanup ordering of vector numbers
x86/mce/amd: Rename setup_APIC_mce
arch/x86/include/asm/entry_arch.h| 3 +
arch/x86/include/asm/hardirq.h
are introduced.
Aravind Gopalakrishnan (4):
x86/mce: Define 'SUCCOR' cpuid bit
x86/mce/amd: Introduce deferred error interrupt handler
x86, irq: Cleanup ordering of vector numbers
x86/mce/amd: Rename setup_APIC_mce
arch/x86/include/asm/entry_arch.h| 3 +
arch/x86/include/asm/hardirq.h
'setup_APIC_mce' doesn't give us an indication of why we are
going to program LVT. Make that explicit by renaming it to
setup_APIC_mce_threshold so we know.
No functional change is introduced.
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/kernel/cpu/mcheck
Enforcing proper descending order of vector number assignments here.
No functional change.
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/include/asm/irq_vectors.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include
-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/include/asm/mce.h | 3 ++-
arch/x86/kernel/cpu/mcheck/mce.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 1f5a86d..dfcb664 100644
Deferred error interrupt stats on
/proc/interrupts by incrementing irq_deferred_count
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/include/asm/entry_arch.h| 3 +
arch/x86/include/asm/hardirq.h | 3 +
arch/x86/include/asm/hw_irq.h
On 4/30/15 3:41 PM, Andy Lutomirski wrote:
On Thu, Apr 30, 2015 at 7:49 AM, Aravind Gopalakrishnan
aravind.gopalakrish...@amd.com wrote:
Changes introduced in the patch-
- Assign vector number 0xf4 for Deferred errors
- Declare deferred_interrupt, allocate gate and bind
safely postulate that future
AMD processors will support 8-bit APIC IDs and we can simply set that
feature bit on them, without the PCI access.
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/kernel/cpu/amd.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch
safely postulate that future
AMD processors will support 8-bit APIC IDs and we can simply set that
feature bit on them, without the PCI access.
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/kernel/cpu/amd.c | 12 ++--
1 file changed, 10 insertions(+), 2
Commit-ID: b44915927ca88084a7292e4ddd4cf91036f365e1
Gitweb: http://git.kernel.org/tip/b44915927ca88084a7292e4ddd4cf91036f365e1
Author: Aravind Gopalakrishnan
AuthorDate: Thu, 9 Apr 2015 10:51:48 +0200
Committer: Ingo Molnar
CommitDate: Thu, 9 Apr 2015 10:56:31 +0200
x86/iommu: Fix
Commit-ID: b44915927ca88084a7292e4ddd4cf91036f365e1
Gitweb: http://git.kernel.org/tip/b44915927ca88084a7292e4ddd4cf91036f365e1
Author: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
AuthorDate: Thu, 9 Apr 2015 10:51:48 +0200
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu
ix that.
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/include/asm/iommu_table.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/iommu_table.h
b/arch/x86/include/asm/iommu_table.h
index f42a047..16845d4 100644
--- a/arch/x86/include/asm/iommu_table.h
++
-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/include/asm/iommu_table.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/iommu_table.h
b/arch/x86/include/asm/iommu_table.h
index f42a047..16845d4 100644
--- a/arch/x86/include/asm
bail early
as they don't have GART.
Signed-off-by: Aravind Gopalakrishnan
Reviewed-by: Suravee Suthikulpanit
Cc: Joerg Rodel
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: Bjorn Helgaas
Cc: x86-ml
---
Changes in V2:
- move amd_gart_present() before any other checks as it's least
On 4/7/2015 9:57 AM, Borislav Petkov wrote:
On Tue, Apr 07, 2015 at 09:46:26AM -0500, Aravind Gopalakrishnan wrote:
Okay. I'll do that and correct the typos Ingo pointed out earlier and
resend.
Btw, I think you should do the same in early_gart_iommu_check() too.
Doing the testing this way
On 4/7/2015 7:34 AM, Borislav Petkov wrote:
On Mon, Apr 06, 2015 at 06:10:22PM -0500, Aravind Gopalakrishnan wrote:
So what happens if !early_pci_allowed() but the GART is present? We'll
set amd_northbridges.flags |= AMD_NB_GART, but won't run any of the
setup code in aperture_64.c, right
On 4/7/2015 7:34 AM, Borislav Petkov wrote:
On Mon, Apr 06, 2015 at 06:10:22PM -0500, Aravind Gopalakrishnan wrote:
So what happens if !early_pci_allowed() but the GART is present? We'll
set amd_northbridges.flags |= AMD_NB_GART, but won't run any of the
setup code in aperture_64.c, right
On 4/7/2015 9:57 AM, Borislav Petkov wrote:
On Tue, Apr 07, 2015 at 09:46:26AM -0500, Aravind Gopalakrishnan wrote:
Okay. I'll do that and correct the typos Ingo pointed out earlier and
resend.
Btw, I think you should do the same in early_gart_iommu_check() too.
Doing the testing this way
bail early
as they don't have GART.
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
Reviewed-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
Cc: Joerg Rodel j...@8bytes.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: H. Peter Anvin h
On 4/2/2015 1:19 PM, Ingo Molnar wrote:
+ if (amd_gart_present())
amd_northbridges.flags |= AMD_NB_GART;
/*
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 76164e173a24..1cb170b06853 100644
--- a/arch/x86/kernel/aperture_64.c
+++
On 4/2/2015 1:19 PM, Ingo Molnar wrote:
+ if (amd_gart_present())
amd_northbridges.flags |= AMD_NB_GART;
/*
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 76164e173a24..1cb170b06853 100644
--- a/arch/x86/kernel/aperture_64.c
+++
On 4/2/2015 11:53 AM, Borislav Petkov wrote:
On Thu, Apr 02, 2015 at 11:23:17AM -0500, Aravind Gopalakrishnan wrote:
Sure, will do that and resend.
No need - I can amend the local copy I have here.
Okay.
Thanks!
-Aravind.
--
To unsubscribe from this list: send the line "unsubscribe
On 4/2/2015 11:06 AM, Ingo Molnar wrote:
We get "AGP:" messages on kernel logs like this-
[0.00] AGP: Node 0: aperture [bus addr 0x-0x01ff] (32MB)
[0.00] AGP: Your BIOS doesn't leave a aperture memory hole
[0.00] AGP: Please enable the IOMMU option in the
On 4/2/2015 5:01 AM, Ingo Molnar wrote:
* Aravind Gopalakrishnan wrote:
GART registers are not present in newer processors (Fam15h, Model 10h
and later). So, avoid accesses to GART registers in PCI config
space by returning early in early_gart_iommu_check() and
gart_iommu_hole_init() if GART
On 4/2/2015 5:01 AM, Ingo Molnar wrote:
* Aravind Gopalakrishnan aravind.gopalakrish...@amd.com wrote:
GART registers are not present in newer processors (Fam15h, Model 10h
and later). So, avoid accesses to GART registers in PCI config
space by returning early in early_gart_iommu_check
On 4/2/2015 11:06 AM, Ingo Molnar wrote:
We get AGP: messages on kernel logs like this-
[0.00] AGP: Node 0: aperture [bus addr 0x-0x01ff] (32MB)
[0.00] AGP: Your BIOS doesn't leave a aperture memory hole
[0.00] AGP: Please enable the IOMMU option in the BIOS
On 4/2/2015 11:53 AM, Borislav Petkov wrote:
On Thu, Apr 02, 2015 at 11:23:17AM -0500, Aravind Gopalakrishnan wrote:
Sure, will do that and resend.
No need - I can amend the local copy I have here.
Okay.
Thanks!
-Aravind.
--
To unsubscribe from this list: send the line unsubscribe linux
function
so we can use it here as well as in amd_nb.c
Tested the patch on Fam10h and Fam15h Model 00h-fh and this code
runs fine. On Fam15h Model 60h-6fh and on Fam16h, we bail early
as they don't have GART.
Signed-off-by: Aravind Gopalakrishnan
Reviewed-by: Suravee Suthikulpanit
---
arch/x86
function
so we can use it here as well as in amd_nb.c
Tested the patch on Fam10h and Fam15h Model 00h-fh and this code
runs fine. On Fam15h Model 60h-6fh and on Fam16h, we bail early
as they don't have GART.
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
Reviewed-by: Suravee
y Boris.
No functional changes are introduced by the patch
Reported-by: Dan Carpenter
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/kernel/cpu/mcheck/mce-severity.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce-severity.c
b/arch/x86
.
No functional changes are introduced by the patch
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/kernel/cpu/mcheck/mce-severity.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86
On 3/30/2015 4:43 AM, Borislav Petkov wrote:
On Mon, Mar 30, 2015 at 11:26:34AM +0200, Geert Uytterhoeven wrote:
On Sun, Mar 29, 2015 at 3:56 PM, Borislav Petkov wrote:
From: Borislav Petkov
Let's make it official - I've been doing this for a while now anyway.
Signed-off-by: Borislav
On 3/30/2015 4:43 AM, Borislav Petkov wrote:
On Mon, Mar 30, 2015 at 11:26:34AM +0200, Geert Uytterhoeven wrote:
On Sun, Mar 29, 2015 at 3:56 PM, Borislav Petkov b...@alien8.de wrote:
From: Borislav Petkov b...@suse.de
Let's make it official - I've been doing this for a while now anyway.
On 3/24/2015 10:18 AM, Borislav Petkov wrote:
On Tue, Mar 24, 2015 at 10:02:33AM -0500, Aravind Gopalakrishnan wrote:
I think the clean way to fix this would be to move the line to [patch 2/2].
Besides, we would need a new patch 2 anyway as the patch application would
fail due to changes
On 3/24/2015 3:30 AM, Borislav Petkov wrote:
On Mon, Mar 23, 2015 at 10:42:52AM -0500, Aravind Gopalakrishnan wrote:
+/* keeping mce_severity_amd in sync with AMD error scope heirarchy table */
Which table do you mean?
I changed it to:
/*
* See AMD Error Scope Hierarchy table in a newer
On 3/24/2015 3:30 AM, Borislav Petkov wrote:
On Mon, Mar 23, 2015 at 10:42:52AM -0500, Aravind Gopalakrishnan wrote:
+/* keeping mce_severity_amd in sync with AMD error scope heirarchy table */
Which table do you mean?
I changed it to:
/*
* See AMD Error Scope Hierarchy table in a newer
On 3/24/2015 10:18 AM, Borislav Petkov wrote:
On Tue, Mar 24, 2015 at 10:02:33AM -0500, Aravind Gopalakrishnan wrote:
I think the clean way to fix this would be to move the line to [patch 2/2].
Besides, we would need a new patch 2 anyway as the patch application would
fail due to changes
Luck
Signed-off-by: Aravind Gopalakrishnan
---
Changes from V2: (per Boris suggestion)
- use mce_severity_intel for default and only override it for AMD systems
- remove switch and use simple if for checking if we are on AMD processor
arch/x86/include/asm/mce.h| 2 ++
arch
of the flags field.
This is based off of work by Boris Petkov.
Testing details:
Tested the patch for any regressions on
Fam10h, Model 9h (Greyhound)
Fam15h: Models 0h-0fh (Orochi), 30h-3fh (Kaveri) and 60h-6fh (Carrizo),
Fam16h Model 00h-0fh (Kabini)
Signed-off-by: Aravind Gopalakrishnan
---
Changes
Patch1: Introduce AMD severities function
Patch2: Initialise mce_severity function pointer to mce_severity_intel
and override it to mce_severity_amd on AMD systems
Aravind Gopalakrishnan (2):
x86, mce, severities: Add AMD severities function
x86, mce, severities: Define mce_severity
On 3/21/2015 1:10 AM, Borislav Petkov wrote:
On Fri, Mar 20, 2015 at 09:35:26PM -0500, Aravind Gopalakrishnan wrote:
Other function pointers in the mce code like unexpected_machine_check
and default_threshold_interrupt are assigned to the respective
function pointers when they are defined
On 3/21/2015 1:10 AM, Borislav Petkov wrote:
On Fri, Mar 20, 2015 at 09:35:26PM -0500, Aravind Gopalakrishnan wrote:
Other function pointers in the mce code like unexpected_machine_check
and default_threshold_interrupt are assigned to the respective
function pointers when they are defined
Patch1: Introduce AMD severities function
Patch2: Initialise mce_severity function pointer to mce_severity_intel
and override it to mce_severity_amd on AMD systems
Aravind Gopalakrishnan (2):
x86, mce, severities: Add AMD severities function
x86, mce, severities: Define mce_severity
Luck tony.l...@intel.com
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
Changes from V2: (per Boris suggestion)
- use mce_severity_intel for default and only override it for AMD systems
- remove switch and use simple if for checking if we are on AMD processor
arch/x86
of the flags field.
This is based off of work by Boris Petkov.
Testing details:
Tested the patch for any regressions on
Fam10h, Model 9h (Greyhound)
Fam15h: Models 0h-0fh (Orochi), 30h-3fh (Kaveri) and 60h-6fh (Carrizo),
Fam16h Model 00h-0fh (Kabini)
Signed-off-by: Aravind Gopalakrishnan
On 3/20/15 5:31 PM, Luck, Tony wrote:
+ default:
+ WARN_ONCE(1, "WTF!?");
+ break;
You meant to type:
mce_severity = mce_severity_default;
just there, right?
Other function pointers in the mce code like unexpected_machine_check
and
cleaner to do it this way.
Suggested-by: Tony Luck
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/include/asm/mce.h| 2 ++
arch/x86/kernel/cpu/mcheck/mce-internal.h | 3 ++-
arch/x86/kernel/cpu/mcheck/mce-severity.c | 35 ++-
arch/x86/kernel/cpu
Patch1: Introduce AMD severities function
Patch2: Initialise mce_severity function pointer to choose between
Intel or AMD grading mechanisms
Aravind Gopalakrishnan (2):
x86, mce, severities: Add AMD severities function
x86, mce, severities: Define mce_severity function pointer
arch
of the flags field.
This is based off of work by Boris Petkov.
Testing details:
Tested the patch for any regressions on F15hM0h-0fh (Orochi)
and F15hM60h-6fh (Carrizo) and it works fine.
Signed-off-by: Aravind Gopalakrishnan
---
Changes from V1:
- Test mce_flags.overflow_recov once instead of multiple
On 3/19/2015 12:15 PM, Luck, Tony wrote:
It would be best if what Tony suggested comes ontop of your patch with
his Suggested-by: tag. This ordering should be also the easiest wrt
functionality and bisectability.
Ok, I'll have it ready and send out a V2 by tomorrow if there are no
other
On 3/20/15 5:31 PM, Luck, Tony wrote:
+ default:
+ WARN_ONCE(1, WTF!?);
+ break;
You meant to type:
mce_severity = mce_severity_default;
just there, right?
Other function pointers in the mce code like unexpected_machine_check
and
On 3/19/2015 12:15 PM, Luck, Tony wrote:
It would be best if what Tony suggested comes ontop of your patch with
his Suggested-by: tag. This ordering should be also the easiest wrt
functionality and bisectability.
Ok, I'll have it ready and send out a V2 by tomorrow if there are no
other
Patch1: Introduce AMD severities function
Patch2: Initialise mce_severity function pointer to choose between
Intel or AMD grading mechanisms
Aravind Gopalakrishnan (2):
x86, mce, severities: Add AMD severities function
x86, mce, severities: Define mce_severity function pointer
arch
of the flags field.
This is based off of work by Boris Petkov.
Testing details:
Tested the patch for any regressions on F15hM0h-0fh (Orochi)
and F15hM60h-6fh (Carrizo) and it works fine.
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
Changes from V1:
- Test
cleaner to do it this way.
Suggested-by: Tony Luck tony.l...@intel.com
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/include/asm/mce.h| 2 ++
arch/x86/kernel/cpu/mcheck/mce-internal.h | 3 ++-
arch/x86/kernel/cpu/mcheck/mce-severity.c | 35
On 3/19/2015 10:53 AM, Borislav Petkov wrote:
On Thu, Mar 19, 2015 at 09:41:01AM -0500, Aravind Gopalakrishnan wrote:
Ok, I'll work on this and prepend the changes to the current version
of the patch. Would you prefer the changes be in a separate patch or
lump it in along with current version
On 3/19/2015 4:29 AM, Borislav Petkov wrote:
On Thu, Mar 19, 2015 at 12:01:32AM +, Luck, Tony wrote:
One other thought. Instead of the run-time test to see if this is an AMD
processor on every call
to this function, would it be cleaner to:
1) Rename existing mce_severity() function to
On 3/19/2015 4:29 AM, Borislav Petkov wrote:
On Thu, Mar 19, 2015 at 12:01:32AM +, Luck, Tony wrote:
One other thought. Instead of the run-time test to see if this is an AMD
processor on every call
to this function, would it be cleaner to:
1) Rename existing mce_severity() function to
On 3/19/2015 10:53 AM, Borislav Petkov wrote:
On Thu, Mar 19, 2015 at 09:41:01AM -0500, Aravind Gopalakrishnan wrote:
Ok, I'll work on this and prepend the changes to the current version
of the patch. Would you prefer the changes be in a separate patch or
lump it in along with current version
On 3/17/2015 5:20 AM, Borislav Petkov wrote:
On Mon, Mar 16, 2015 at 12:16:04PM -0500, Aravind Gopalakrishnan wrote:
+/* keeping amd_mce_severity in sync with AMD error scope heirarchy table */
+static int amd_mce_severity(struct mce *m, enum context ctx)
+{
+ /* Processor Context Corrupt
On 3/17/2015 5:20 AM, Borislav Petkov wrote:
On Mon, Mar 16, 2015 at 12:16:04PM -0500, Aravind Gopalakrishnan wrote:
+/* keeping amd_mce_severity in sync with AMD error scope heirarchy table */
+static int amd_mce_severity(struct mce *m, enum context ctx)
+{
+ /* Processor Context Corrupt
of the flags field.
This is based off of work by Boris Petkov.
Testing details:
Tested the patch for any regressions on F15hM0h-0fh (Orochi)
and F15hM60h-6fh (Carrizo) and it works fine.
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/include/asm/mce.h| 6
arch/x86/kernel/cpu
of the flags field.
This is based off of work by Boris Petkov.
Testing details:
Tested the patch for any regressions on F15hM0h-0fh (Orochi)
and F15hM60h-6fh (Carrizo) and it works fine.
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/include/asm/mce.h
Commit-ID: c796b205b88c775fd220c1a63390bac6a8cdda3f
Gitweb: http://git.kernel.org/tip/c796b205b88c775fd220c1a63390bac6a8cdda3f
Author: Aravind Gopalakrishnan
AuthorDate: Fri, 23 Jan 2015 12:19:35 -0600
Committer: Ingo Molnar
CommitDate: Wed, 18 Feb 2015 17:01:46 +0100
perf/x86/amd/ibs
Commit-ID: c796b205b88c775fd220c1a63390bac6a8cdda3f
Gitweb: http://git.kernel.org/tip/c796b205b88c775fd220c1a63390bac6a8cdda3f
Author: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
AuthorDate: Fri, 23 Jan 2015 12:19:35 -0600
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed
gested-by: Borislav Petkov
Signed-off-by: Aravind Gopalakrishnan
---
Changes in V2:
- earlier changes regarding removal of bank == 4 check and removal
of 'interrupt_enable' attribute causes regressions. Fixed that.
- moving setting of threshold_limit and comment style fixes are not
di
-by: Borislav Petkov b...@suse.de
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
Changes in V2:
- earlier changes regarding removal of bank == 4 check and removal
of 'interrupt_enable' attribute causes regressions. Fixed that.
- moving setting of threshold_limit
ble is set by default
- echo 0 > interrupt_enable clears IntType of respective register
- Forcing error count to go over threshold_limit generates APIC
interrupt and edac mce_amd catches it fine
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/kernel/cpu/mcheck/m
The caller of force_ibs_eilvt_setup() is ibs_eilvt_setup()
which does not care about the return values.
So, marking it void and cleaning up the return statements.
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/kernel/cpu/perf_event_amd_ibs.c | 12 +---
1 file changed, 5 insertions
The caller of force_ibs_eilvt_setup() is ibs_eilvt_setup()
which does not care about the return values.
So, marking it void and cleaning up the return statements.
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/kernel/cpu/perf_event_amd_ibs.c | 12
by default
- echo 0 interrupt_enable clears IntType of respective register
- Forcing error count to go over threshold_limit generates APIC
interrupt and edac mce_amd catches it fine
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/kernel/cpu/mcheck/mce_amd.c
On 1/19/2015 12:21 PM, Borislav Petkov wrote:
On Mon, Jan 19, 2015 at 12:18:58PM -0600, Aravind Gopalakrishnan wrote:
The NodeId field in cpuid_ecx(0x801e) is a 8 bit field.
Although current extractor works fine, it will break if/when
the most significant 5 bits ever get used.
So, lets
On 1/19/2015 12:21 PM, Borislav Petkov wrote:
On Mon, Jan 19, 2015 at 12:18:58PM -0600, Aravind Gopalakrishnan wrote:
The NodeId field in cpuid_ecx(0x801e) is a 8 bit field.
Although current extractor works fine, it will break if/when
the most significant 5 bits ever get used.
So, lets
Identifiers
Signed-off-by: Aravind Gopalakrishnan
---
arch/x86/kernel/cpu/amd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index a220239..9942b83 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
Identifiers
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
arch/x86/kernel/cpu/amd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index a220239..9942b83 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b
Hi all,
I had a question regarding the intention of the -D flag after looking at
perf stat numbers of the following workload:
main(){
int a=5, b=6;
int i;
#pragma omp for schedule(dynamic)
for (i=0; i<1000; i++){
b=b+a;
}
return 0;
}
_Stats without delay:_
# perf stat -e
Hi all,
I had a question regarding the intention of the -D flag after looking at
perf stat numbers of the following workload:
main(){
int a=5, b=6;
int i;
#pragma omp for schedule(dynamic)
for (i=0; i1000; i++){
b=b+a;
}
return 0;
}
_Stats without delay:_
# perf stat -e
On 1/7/2015 11:06 AM, Borislav Petkov wrote:
On Tue, Jan 06, 2015 at 05:54:15PM -0600, Aravind Gopalakrishnan wrote:
But we still need to change the error injection interfaces in mce_amd_inj:
mce_amd_inj triggers a #MC on the cpu number that the user specifies on
debugfs.
For any error other
On 1/7/2015 11:06 AM, Borislav Petkov wrote:
On Tue, Jan 06, 2015 at 05:54:15PM -0600, Aravind Gopalakrishnan wrote:
But we still need to change the error injection interfaces in mce_amd_inj:
mce_amd_inj triggers a #MC on the cpu number that the user specifies on
debugfs.
For any error other
On 12/23/2014 1:41 PM, Aravind Gopalakrishnan wrote:
On 12/22/2014 5:19 PM, Borislav Petkov wrote:
On Mon, Dec 22, 2014 at 02:56:47PM -0600, Aravind Gopalakrishnan wrote:
On 12/22/2014 2:15 PM, Borislav Petkov wrote:
On Mon, Dec 22, 2014 at 02:10:09PM -0600, Aravind Gopalakrishnan
wrote
On 12/23/2014 1:41 PM, Aravind Gopalakrishnan wrote:
On 12/22/2014 5:19 PM, Borislav Petkov wrote:
On Mon, Dec 22, 2014 at 02:56:47PM -0600, Aravind Gopalakrishnan wrote:
On 12/22/2014 2:15 PM, Borislav Petkov wrote:
On Mon, Dec 22, 2014 at 02:10:09PM -0600, Aravind Gopalakrishnan
wrote
On 12/22/2014 5:19 PM, Borislav Petkov wrote:
On Mon, Dec 22, 2014 at 02:56:47PM -0600, Aravind Gopalakrishnan wrote:
On 12/22/2014 2:15 PM, Borislav Petkov wrote:
On Mon, Dec 22, 2014 at 02:10:09PM -0600, Aravind Gopalakrishnan wrote:
When a MCE happens that is to be logged onto bank 4
On 12/22/2014 5:19 PM, Borislav Petkov wrote:
On Mon, Dec 22, 2014 at 02:56:47PM -0600, Aravind Gopalakrishnan wrote:
On 12/22/2014 2:15 PM, Borislav Petkov wrote:
On Mon, Dec 22, 2014 at 02:10:09PM -0600, Aravind Gopalakrishnan wrote:
When a MCE happens that is to be logged onto bank 4
301 - 400 of 642 matches
Mail list logo
