[lkml]   [2013]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 0/9] Extended H/W error log driver
On Wed, Oct 16, 2013 at 10:55:57AM -0400, Chen, Gong wrote:
> [PATCH v2 1/9] ACPI, APEI, CPER: Fix status check during error printing
> [PATCH v2 2/9] ACPI, CPER: Update cper info
> [PATCH v2 3/9] bitops: Introduce a more generic BITMASK macro
> [PATCH v2 4/9] ACPI, x86: Extended error log driver for x86 platform
> [PATCH v2 5/9] DMI: Parse memory device (type 17) in SMBIOS
> [PATCH v2 6/9] ACPI, APEI, CPER: Add UEFI 2.4 support for memory error
> [PATCH v2 7/9] ACPI, APEI, CPER: Enhance memory reporting capability
> [PATCH v2 8/9] ACPI, APEI, CPER: Cleanup CPER memory error output format
> [PATCH v2 9/9] ACPI / trace: Add trace interface for eMCA driver
> This patch series adds an enhanced MCA event logging driver provided by Intel.
> Please refer to this link: htpp://
> Certain usages such as Predictive Failure Analysis (PFA) require more
> information about the error than what can be described in processor
> machine check banks. Most server processors log additional information
> about the error in processor uncore registers. Since the addresses
> and layout of these registers vary widely from one processor to another,
> system software cannot readily make use of them. To complicate matters
> further, some of the additionalerror information cannot be constructed

space between "additional" and "error".

> without detailed knowledge about platform topology. This enhanced MCA
> logging driver allows firmware to provide additional error information
> to MCE/CMCI handler and thus addresses this gap.

This paragraph sounds like a very good description of the feature and
should actually be the Kconfig text in patch 4/9.

> After applying this patch series, when a memory corrected error happens,
> we can get following information:
> dmesg output:
> [ 949.545817] {1}Hardware error detected on CPU15
> [ 949.549786] {1}event severity: corrected
> [ 949.549786] {1} Error 0, type: corrected
> [ 949.549786] {1} section_type: memory error
> [ 949.549786] {1} physical_address: 0x0000001057eb0000
> [ 949.549786] {1} DIMM location: Memriser3 CHANNEL A DIMM 0
> [ 949.549786] {1}Above error has been corrected by h/w and require no further action
> [ 949.549786] mce: [Hardware Error]: Machine check events logged
> [ 1010.902124] {2}Hardware error detected on CPU15
> [ 1010.906064] {2}event severity: corrected
> [ 1010.906064] {2} Error 0, type: corrected
> [ 1010.906064] {2} section_type: memory error
> [ 1010.906064] {2} physical_address: 0x0000001057eb0000
> [ 1010.906064] {2} DIMM location: Memriser3 CHANNEL A DIMM 0
> [ 1010.906064] {2}Above error has been corrected by h/w and require no further action
> [ 1010.906064] mce: [Hardware Error]: Machine check events logged

Yep, looks almost very good. One nit: can you raise the action line
higher, like this:

> [ 949.545817] {1}Hardware error detected on CPU15
> [ 949.549786] {1}It has been corrected by h/w and requires no further action

<here come the error details>

I mean, this is only the printk output and with a userspace consumer of
the tracepoint, none of this will go to dmesg but in cases when there's
no userspace consumer, it is still readable and understandable.

> For trace output format we still need further discussion. In the last
> patch(support trace interface) I have to reserve previous Kconfig
> format because I find once I put trace_event interface in the module,
> it will not work. I will paste another trace patch(it only works when
> acpi_extlog is builtin) for your answer.

I think to be able to define TRACE_EVENTs in modules, you need

Steve, that still true?


Sent from a fat crate under my desk. Formatting is fine.

 \ /
  Last update: 2013-10-16 22:21    [W:0.299 / U:2.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site