On Fri, Dec 06, 2013 at 11:11:07PM +0800, Ethan Zhao wrote:
> > @@ -63,10 +63,10 @@ TRACE_EVENT(aer_event,
> >
> > TP_printk("%s PCIe Bus Error: severity=%s, %s\n",
> > __get_str(dev_name),
> > - __entry->severity == HW_EVENT_ERR_CORRECTED ? "Corrected" :
> >
On Fri, Dec 06, 2013 at 11:11:07PM +0800, Ethan Zhao wrote:
@@ -63,10 +63,10 @@ TRACE_EVENT(aer_event,
TP_printk(%s PCIe Bus Error: severity=%s, %s\n,
__get_str(dev_name),
- __entry-severity == HW_EVENT_ERR_CORRECTED ? Corrected :
-
On Fri, Dec 6, 2013 at 5:06 PM, rui wang wrote:
> On 12/5/13, Borislav Petkov wrote:
>
>> Yes, the AER tracepoint above should use the AER_* defines and not the
>> HW_EVENT_ERR_* ones which are for memory errors.
>>
>> Wanna send a fix?
>>
>
> Yes. Does it translate into something like this?
>
>
On 12/5/13, Borislav Petkov wrote:
> Yes, the AER tracepoint above should use the AER_* defines and not the
> HW_EVENT_ERR_* ones which are for memory errors.
>
> Wanna send a fix?
>
Yes. Does it translate into something like this?
From: Rui Wang
Date: Fri, 6 Dec 2013 16:47:46 +0800
Subject:
On 12/5/13, Borislav Petkov b...@alien8.de wrote:
Yes, the AER tracepoint above should use the AER_* defines and not the
HW_EVENT_ERR_* ones which are for memory errors.
Wanna send a fix?
Yes. Does it translate into something like this?
From: Rui Wang rui.y.w...@intel.com
Date: Fri, 6 Dec
On Fri, Dec 6, 2013 at 5:06 PM, rui wang ruiv.w...@gmail.com wrote:
On 12/5/13, Borislav Petkov b...@alien8.de wrote:
Yes, the AER tracepoint above should use the AER_* defines and not the
HW_EVENT_ERR_* ones which are for memory errors.
Wanna send a fix?
Yes. Does it translate into
On Thu, Dec 05, 2013 at 11:21:10AM -0700, Betty Dall wrote:
> The definition of the GHES_SEV* matches up with the error severity
> definition of the CPER records as defined in the UEFI spec section
> N.2.1:
> "Indicates the severity of the error condition. The severity of
> the error record
On Wed, 2013-12-04 at 23:28 +0800, Ethan Zhao wrote:
> Rui,
>Agree with that, there are really many such confusing error type definition
> need to be standardized or unified, some of them are
> ambiguous、inconsistent, some of them violates ACPI/PCI spec.
>
> According to the ACPI spec, the
On Wed, 2013-12-04 at 23:28 +0800, Ethan Zhao wrote:
Rui,
Agree with that, there are really many such confusing error type definition
need to be standardized or unified, some of them are
ambiguous、inconsistent, some of them violates ACPI/PCI spec.
According to the ACPI spec, the
On Thu, Dec 05, 2013 at 11:21:10AM -0700, Betty Dall wrote:
The definition of the GHES_SEV* matches up with the error severity
definition of the CPER records as defined in the UEFI spec section
N.2.1:
Indicates the severity of the error condition. The severity of
the error record corresponds
On Mon, Dec 02, 2013 at 01:05:16PM +0800, rui wang wrote:
> > + TP_printk("%s PCIe Bus Error: severity=%s, %s\n",
> > + __get_str(dev_name),
> > + __entry->severity == HW_EVENT_ERR_CORRECTED ? "Corrected" :
> > + __entry->severity == HW_EVENT_ERR_FATAL ?
> >
Rui,
Agree with that, there are really many such confusing error type definition
need to be standardized or unified, some of them are
ambiguous、inconsistent, some of them violates ACPI/PCI spec.
According to the ACPI spec, the 'FATAL' in fact, is a sub-category
of 'UNCORRECTABLE' , the
Rui,
Agree with that, there are really many such confusing error type definition
need to be standardized or unified, some of them are
ambiguous、inconsistent, some of them violates ACPI/PCI spec.
According to the ACPI spec, the 'FATAL' in fact, is a sub-category
of 'UNCORRECTABLE' , the
On Mon, Dec 02, 2013 at 01:05:16PM +0800, rui wang wrote:
+ TP_printk(%s PCIe Bus Error: severity=%s, %s\n,
+ __get_str(dev_name),
+ __entry-severity == HW_EVENT_ERR_CORRECTED ? Corrected :
+ __entry-severity == HW_EVENT_ERR_FATAL ?
+
Resending adding Mauro's new Email address...
On 1/17/13, Lance Ortiz wrote:
> This header file will define a new trace event that will be triggered when
> a AER event occurs. The following data will be provided to the trace
> event.
>
> char * dev_name - The name of the slot where the device
Resending adding Mauro's new Email address...
On 1/17/13, Lance Ortiz lance.or...@hp.com wrote:
This header file will define a new trace event that will be triggered when
a AER event occurs. The following data will be provided to the trace
event.
char * dev_name - The name of the slot
On 1/17/13, Lance Ortiz wrote:
> This header file will define a new trace event that will be triggered when
> a AER event occurs. The following data will be provided to the trace
> event.
>
> char * dev_name - The name of the slot where the device resides
>
On 1/17/13, Lance Ortiz lance.or...@hp.com wrote:
This header file will define a new trace event that will be triggered when
a AER event occurs. The following data will be provided to the trace
event.
char * dev_name - The name of the slot where the device resides
This header file will define a new trace event that will be triggered when
a AER event occurs. The following data will be provided to the trace
event.
char * dev_name - The name of the slot where the device resides
([domain:]bus:device.function).
u32 status - Either the
This header file will define a new trace event that will be triggered when
a AER event occurs. The following data will be provided to the trace
event.
char * dev_name - The name of the slot where the device resides
([domain:]bus:device.function).
u32 status - Either the
20 matches
Mail list logo
