2012-11-29 21:59:46

by Lance Ortiz

[permalink] [raw]
Subject: [PATCH 1/3] aerdrv: Trace Event for AER

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 * name - String containing the device path

u32 status - Either the correctable or uncorrectable register
indicating what error or errors have been see.

u8 severity - error severity 0:NONFATAL 1:FATAL 2:CORRECTED

The trace event will also provide a trace string that may look like:

"0000:05:00.0 PCIe Bus Error:severity=Uncorrected (Non-Fatal), Poisoned
TLP"

Signed-off-by: Lance Ortiz <[email protected]>
---

include/ras/aer_event.h | 77 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 77 insertions(+), 0 deletions(-)
create mode 100644 include/ras/aer_event.h

diff --git a/include/ras/aer_event.h b/include/ras/aer_event.h
new file mode 100644
index 0000000..735c973
--- /dev/null
+++ b/include/ras/aer_event.h
@@ -0,0 +1,77 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM aer
+#define TRACE_INCLUDE_FILE aer_event
+
+#if !defined(_TRACE_AER_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_AER_H
+
+#include <linux/tracepoint.h>
+#include <linux/edac.h>
+
+
+/*
+ * Anhance Error Reporting (AER) PCIE Report Error
+ *
+ * These events are generated when hardware detects a corrected or
+ * uncorrected event on a pci express device and reports
+ * errors. The event reports the following data.
+ *
+ * char * dev_name - String containing the device identification
+ * u32 status - Either the correctable or uncorrectable register
+ * indicating what error or errors have been seen
+ * u8 severity - error severity 0:NONFATAL 1:FATAL 2:CORRECTED
+ */
+
+#define correctable_error_string \
+ {BIT(0), "Receiver Error"}, \
+ {BIT(6), "Bad TLP"}, \
+ {BIT(7), "Bad DLLP"}, \
+ {BIT(8), "RELAY_NUM Rollover"}, \
+ {BIT(12), "Replay Timer Timeout"}, \
+ {BIT(13), "Advisory Non-Fatal"}
+
+#define uncorrectable_error_string \
+ {BIT(4), "Data Link Protocol"}, \
+ {BIT(12), "Poisoned TLP"}, \
+ {BIT(13), "Flow Control Protocol"}, \
+ {BIT(14), "Completion Timeout"}, \
+ {BIT(15), "Completer Abort"}, \
+ {BIT(16), "Unexpected Completion"}, \
+ {BIT(17), "Receiver Overflow"}, \
+ {BIT(18), "Malformed TLP"}, \
+ {BIT(19), "ECRC"}, \
+ {BIT(20), "Unsupported Request"}
+
+TRACE_EVENT(aer_event,
+ TP_PROTO(const char *dev_name,
+ const u32 status,
+ const u8 severity),
+
+ TP_ARGS(dev_name, status, severity),
+
+ TP_STRUCT__entry(
+ __string( dev_name, dev_name )
+ __field( u32, status )
+ __field( u8, severity )
+ ),
+
+ TP_fast_assign(
+ __assign_str(dev_name, dev_name);
+ __entry->status = status;
+ __entry->severity = severity;
+ ),
+
+ 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) ?
+ "Fatal" : "Uncorrected"),
+ __entry->severity == HW_EVENT_ERR_CORRECTED ?
+ __print_flags(__entry->status, "|", correctable_error_string) :
+ __print_flags(__entry->status, "|", uncorrectable_error_string))
+);
+
+#endif /* _TRACE_AER_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>


2012-11-29 21:59:53

by Lance Ortiz

[permalink] [raw]
Subject: [PATCH 2/3] aerdrv: Enhanced AER logging

This patch will provide a more reliable and easy way for user-space
applications to have access to AER logs rather than reading them from the
message buffer. It also provides a way to notify user-space when an AER
event occurs.

The aer driver is updated to generate a trace event of function 'aer_event'
when an AER occurs. The trace event was added to both the interrupt
based aer path and the firmware first path

Signed-off-by: Lance Ortiz <[email protected]>
---

drivers/acpi/apei/cper.c | 11 +++++++++--
drivers/pci/pcie/aer/aerdrv_errprint.c | 11 ++++++++++-
2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
index e6defd8..ef1e1c0 100644
--- a/drivers/acpi/apei/cper.c
+++ b/drivers/acpi/apei/cper.c
@@ -281,9 +281,16 @@ static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
"%s""bridge: secondary_status: 0x%04x, control: 0x%04x\n",
pfx, pcie->bridge.secondary_status, pcie->bridge.control);
#ifdef CONFIG_ACPI_APEI_PCIEAER
- if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO) {
+ dev = pci_get_domain_bus_and_slot(pcie->device_id.segment,
+ pcie->device_id.bus, pcie->device_id.function);
+ if (!dev)
+ pr_info(KERN_INFO, "PCI AER Cannot get PCI device %04x:%02x:%02x.%d\n",
+ domain, bus, slot, func);
+
+ if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO && dev) {
struct aer_capability_regs *aer_regs = (void *)pcie->aer_info;
- cper_print_aer(pfx, gdata->error_severity, aer_regs);
+ cper_print_aer(dev, gdata->error_severity, aer_regs);
+ pci_dev_put(dev);
}
#endif
}
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 3ea5173..6354e50 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -23,6 +23,10 @@

#include "aerdrv.h"

+#define CREATE_TRACE_POINTS
+#define TRACE_INCLUDE_PATH ../../../../include/ras
+#include <ras/aer_event.h>
+
#define AER_AGENT_RECEIVER 0
#define AER_AGENT_REQUESTER 1
#define AER_AGENT_COMPLETER 2
@@ -194,6 +198,8 @@ void aer_print_error(struct pci_dev *dev, struct aer_err_info *info)
if (info->id && info->error_dev_num > 1 && info->id == id)
printk("%s"" Error of this Agent(%04x) is reported first\n",
prefix, id);
+ trace_aer_event(dev_name(&dev->dev), (info->status & ~info->mask),
+ info->severity);
}

void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info)
@@ -217,12 +223,13 @@ int cper_severity_to_aer(int cper_severity)
}
EXPORT_SYMBOL_GPL(cper_severity_to_aer);

-void cper_print_aer(const char *prefix, int cper_severity,
+void cper_print_aer(struct pci_dev *dev, int cper_severity,
struct aer_capability_regs *aer)
{
int aer_severity, layer, agent, status_strs_size, tlp_header_valid = 0;
u32 status, mask;
const char **status_strs;
+ char *prefix = NULL;

aer_severity = cper_severity_to_aer(cper_severity);
if (aer_severity == AER_CORRECTABLE) {
@@ -259,5 +266,7 @@ void cper_print_aer(const char *prefix, int cper_severity,
*(tlp + 8), *(tlp + 15), *(tlp + 14),
*(tlp + 13), *(tlp + 12));
}
+ trace_aer_event(dev_name(&dev->dev), (status & ~mask),
+ aer_severity);
}
#endif

2012-11-29 21:59:58

by Lance Ortiz

[permalink] [raw]
Subject: [PATCH 3/3] aerdrv: Cleanup log output for CPER based AER

These changes make cper_print_aer more consistent with aer_print_error
which is called in the AER interrupt case. The string in the variable
'prefix' is printed at the beginning of each print statement in
cper_print_aer(). The prefix is a string containing the driver name
and the device's path. Looking up the call path, the value of prefix
is never assigned and is NULL, so when cper_print_aer prints data the
initial string does not get printed. This string is important because
it identifies the device that the error is on. This patch adds code to
create the prefix and print it in the cper_print_aer function. This
patch also calculates the device's agent id so it can be printed.

Signed-off-by: Lance Ortiz <[email protected]>
---

drivers/pci/pcie/aer/aerdrv_errprint.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 6354e50..bc0a091 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -229,7 +229,13 @@ void cper_print_aer(struct pci_dev *dev, int cper_severity,
int aer_severity, layer, agent, status_strs_size, tlp_header_valid = 0;
u32 status, mask;
const char **status_strs;
- char *prefix = NULL;
+ int id = ((dev->bus->number << 8) | dev->devfn);
+ char prefix[44];
+
+ snprintf(prefix, sizeof(prefix), "%s%s %s: ",
+ (info->severity == AER_CORRECTABLE) ?
+ KERN_WARNING : KERN_ERR,
+ dev_driver_string(&dev->dev), dev_name(&dev->dev));

aer_severity = cper_severity_to_aer(cper_severity);
if (aer_severity == AER_CORRECTABLE) {
@@ -249,8 +255,8 @@ void cper_print_aer(struct pci_dev *dev, int cper_severity,
printk("%s""aer_status: 0x%08x, aer_mask: 0x%08x\n",
prefix, status, mask);
cper_print_bits(prefix, status, status_strs, status_strs_size);
- printk("%s""aer_layer=%s, aer_agent=%s\n", prefix,
- aer_error_layer[layer], aer_agent_string[agent]);
+ printk("%s""aer_layer=%s, %d=%04x(%s)\n", prefix,
+ aer_error_layer[layer], id, aer_agent_string[agent]);
if (aer_severity != AER_CORRECTABLE)
printk("%s""aer_uncor_severity: 0x%08x\n",
prefix, aer->uncor_severity);

2012-11-29 22:11:46

by Joe Perches

[permalink] [raw]
Subject: Re: [PATCH 2/3] aerdrv: Enhanced AER logging

On Thu, 2012-11-29 at 14:54 -0700, Lance Ortiz wrote:
> This patch will provide a more reliable and easy way for user-space
> applications to have access to AER logs rather than reading them from the
> message buffer. It also provides a way to notify user-space when an AER
> event occurs.
[]
> diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
> index e6defd8..ef1e1c0 100644
> --- a/drivers/acpi/apei/cper.c
> +++ b/drivers/acpi/apei/cper.c
> @@ -281,9 +281,16 @@ static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
> "%s""bridge: secondary_status: 0x%04x, control: 0x%04x\n",
> pfx, pcie->bridge.secondary_status, pcie->bridge.control);
> #ifdef CONFIG_ACPI_APEI_PCIEAER
> - if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO) {
> + dev = pci_get_domain_bus_and_slot(pcie->device_id.segment,
> + pcie->device_id.bus, pcie->device_id.function);
> + if (!dev)
> + pr_info(KERN_INFO, "PCI AER Cannot get PCI device %04x:%02x:%02x.%d\n",
> + domain, bus, slot, func);

You've not tried this with CONFIG_ACPI_APEI_PCIEAER enabled.

pr_info("PCI AER Cannot get PCI device %04x:%02x:%02x.%d\n",
domain, bus, slot, func);

2012-11-29 22:22:55

by Ortiz, Lance E

[permalink] [raw]
Subject: RE: [PATCH 2/3] aerdrv: Enhanced AER logging

Yup. You are right. I thought I had it enabled, I will send out the new patch soon.

Lance

> -----Original Message-----
> From: Joe Perches [mailto:[email protected]]
> Sent: Thursday, November 29, 2012 3:12 PM
> To: Ortiz, Lance E
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]
> Subject: Re: [PATCH 2/3] aerdrv: Enhanced AER logging
>
> On Thu, 2012-11-29 at 14:54 -0700, Lance Ortiz wrote:
> > This patch will provide a more reliable and easy way for user-space
> > applications to have access to AER logs rather than reading them from
> the
> > message buffer. It also provides a way to notify user-space when an
> AER
> > event occurs.
> []
> > diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
> > index e6defd8..ef1e1c0 100644
> > --- a/drivers/acpi/apei/cper.c
> > +++ b/drivers/acpi/apei/cper.c
> > @@ -281,9 +281,16 @@ static void cper_print_pcie(const char *pfx,
> const struct cper_sec_pcie *pcie,
> > "%s""bridge: secondary_status: 0x%04x, control: 0x%04x\n",
> > pfx, pcie->bridge.secondary_status, pcie->bridge.control);
> > #ifdef CONFIG_ACPI_APEI_PCIEAER
> > - if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO) {
> > + dev = pci_get_domain_bus_and_slot(pcie->device_id.segment,
> > + pcie->device_id.bus, pcie->device_id.function);
> > + if (!dev)
> > + pr_info(KERN_INFO, "PCI AER Cannot get PCI device
> %04x:%02x:%02x.%d\n",
> > + domain, bus, slot, func);
>
> You've not tried this with CONFIG_ACPI_APEI_PCIEAER enabled.
>
> pr_info("PCI AER Cannot get PCI device
> %04x:%02x:%02x.%d\n",
> domain, bus, slot, func);
>

2012-11-30 01:51:25

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH 1/3] aerdrv: Trace Event for AER

On Thu, 2012-11-29 at 14:54 -0700, 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 * name - String containing the device path
>
> u32 status - Either the correctable or uncorrectable register
> indicating what error or errors have been see.
>
> u8 severity - error severity 0:NONFATAL 1:FATAL 2:CORRECTED
>
> The trace event will also provide a trace string that may look like:
>
> "0000:05:00.0 PCIe Bus Error:severity=Uncorrected (Non-Fatal), Poisoned
> TLP"
>
> Signed-off-by: Lance Ortiz <[email protected]>
> ---
>
> include/ras/aer_event.h | 77 +++++++++++++++++++++++++++++++++++++++++++++++

Is there a reason this header is here? Egad, I never noticed the
ras_event.h that is there. This include/ras directory was created for
the sole purpose of trace events! This is not the way to do this.

Please look at the sample in samples/trace_events/

The proper way is to keep the header by the driver. Then you can simply
include the header with "aer_event.h".

But to have the macro magic work, you need to modify the Makefile to
have something like:

CFLAGS_aerdrv_errprint.o = -I$(src)

and it will be able to find your headers without a problem.
The ras_event.h needs to be fixed too. I may just send a patch myself.

-- Steve


> 1 files changed, 77 insertions(+), 0 deletions(-)
> create mode 100644 include/ras/aer_event.h
>
> diff --git a/include/ras/aer_event.h b/include/ras/aer_event.h
> new file mode 100644
> index 0000000..735c973
> --- /dev/null
> +++ b/include/ras/aer_event.h
> @@ -0,0 +1,77 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM aer
> +#define TRACE_INCLUDE_FILE aer_event
> +
> +#if !defined(_TRACE_AER_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_AER_H
> +
> +#include <linux/tracepoint.h>
> +#include <linux/edac.h>
> +
> +
> +/*
> + * Anhance Error Reporting (AER) PCIE Report Error
> + *
> + * These events are generated when hardware detects a corrected or
> + * uncorrected event on a pci express device and reports
> + * errors. The event reports the following data.
> + *
> + * char * dev_name - String containing the device identification
> + * u32 status - Either the correctable or uncorrectable register
> + * indicating what error or errors have been seen
> + * u8 severity - error severity 0:NONFATAL 1:FATAL 2:CORRECTED
> + */
> +
> +#define correctable_error_string \
> + {BIT(0), "Receiver Error"}, \
> + {BIT(6), "Bad TLP"}, \
> + {BIT(7), "Bad DLLP"}, \
> + {BIT(8), "RELAY_NUM Rollover"}, \
> + {BIT(12), "Replay Timer Timeout"}, \
> + {BIT(13), "Advisory Non-Fatal"}
> +
> +#define uncorrectable_error_string \
> + {BIT(4), "Data Link Protocol"}, \
> + {BIT(12), "Poisoned TLP"}, \
> + {BIT(13), "Flow Control Protocol"}, \
> + {BIT(14), "Completion Timeout"}, \
> + {BIT(15), "Completer Abort"}, \
> + {BIT(16), "Unexpected Completion"}, \
> + {BIT(17), "Receiver Overflow"}, \
> + {BIT(18), "Malformed TLP"}, \
> + {BIT(19), "ECRC"}, \
> + {BIT(20), "Unsupported Request"}
> +
> +TRACE_EVENT(aer_event,
> + TP_PROTO(const char *dev_name,
> + const u32 status,
> + const u8 severity),
> +
> + TP_ARGS(dev_name, status, severity),
> +
> + TP_STRUCT__entry(
> + __string( dev_name, dev_name )
> + __field( u32, status )
> + __field( u8, severity )
> + ),
> +
> + TP_fast_assign(
> + __assign_str(dev_name, dev_name);
> + __entry->status = status;
> + __entry->severity = severity;
> + ),
> +
> + 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) ?
> + "Fatal" : "Uncorrected"),
> + __entry->severity == HW_EVENT_ERR_CORRECTED ?
> + __print_flags(__entry->status, "|", correctable_error_string) :
> + __print_flags(__entry->status, "|", uncorrectable_error_string))
> +);
> +
> +#endif /* _TRACE_AER_H */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>

2012-11-30 01:53:52

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH 2/3] aerdrv: Enhanced AER logging

On Thu, 2012-11-29 at 14:54 -0700, Lance Ortiz wrote:

> --- a/drivers/pci/pcie/aer/aerdrv_errprint.c
> +++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
> @@ -23,6 +23,10 @@
>
> #include "aerdrv.h"
>
> +#define CREATE_TRACE_POINTS
> +#define TRACE_INCLUDE_PATH ../../../../include/ras
> +#include <ras/aer_event.h>
> +

Yuck yuck yuck!

This header should be in the same directory, and you should have in that
same header:

#undef TRACE_INCLUDE_PATH
#define TRACE_INCLUDE_PATH .

and remove the definition here.

-- Steve

> #define AER_AGENT_RECEIVER 0
> #define AER_AGENT_REQUESTER 1
> #define AER_AGENT_COMPLETER 2
> @@ -194,6 +198,8 @@ void aer_print_error(struct pci_dev *dev, struct aer_err_info *info)
> if (info->id && info->error_dev_num > 1 && info->id == id)
> printk("%s"" Error of this Agent(%04x) is reported first\n",
> prefix, id);
> + trace_aer_event(dev_name(&dev->dev), (info->status & ~info->mask),
> + info->severity);
> }
>

2012-11-30 10:53:19

by Borislav Petkov

[permalink] [raw]
Subject: Re: [PATCH 1/3] aerdrv: Trace Event for AER

On Thu, Nov 29, 2012 at 08:51:19PM -0500, Steven Rostedt wrote:
> > include/ras/aer_event.h | 77 +++++++++++++++++++++++++++++++++++++++++++++++
>
> Is there a reason this header is here? Egad, I never noticed the
> ras_event.h that is there. This include/ras directory was created for
> the sole purpose of trace events! This is not the way to do this.

Well, the idea for the ras event was to be able to use it in multiple
places. It is currently used only by EDAC but it could be that memory
errors could be reported by other agents which would reuse that TP.

> Please look at the sample in samples/trace_events/
>
> The proper way is to keep the header by the driver. Then you can simply
> include the header with "aer_event.h".
>
> But to have the macro magic work, you need to modify the Makefile to
> have something like:
>
> CFLAGS_aerdrv_errprint.o = -I$(src)

So I'm guessing that every .c file including the TP should also -I
include the TP definition header wherever it is. Is that agreeable?

Thanks.

--
Regards/Gruss,
Boris.

2012-11-30 11:39:15

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH 1/3] aerdrv: Trace Event for AER

On Fri, 2012-11-30 at 11:53 +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 08:51:19PM -0500, Steven Rostedt wrote:
> > > include/ras/aer_event.h | 77 +++++++++++++++++++++++++++++++++++++++++++++++
> >
> > Is there a reason this header is here? Egad, I never noticed the
> > ras_event.h that is there. This include/ras directory was created for
> > the sole purpose of trace events! This is not the way to do this.
>
> Well, the idea for the ras event was to be able to use it in multiple
> places. It is currently used only by EDAC but it could be that memory
> errors could be reported by other agents which would reuse that TP.
>

If it's generic, then place it into the include/trace/events directory,
the you don't need to have the TRACE_INCLUDE_PATH as that is the default
path the macros will use.

> > Please look at the sample in samples/trace_events/
> >
> > The proper way is to keep the header by the driver. Then you can simply
> > include the header with "aer_event.h".
> >
> > But to have the macro magic work, you need to modify the Makefile to
> > have something like:
> >
> > CFLAGS_aerdrv_errprint.o = -I$(src)
>
> So I'm guessing that every .c file including the TP should also -I
> include the TP definition header wherever it is. Is that agreeable?

You only need the -I$(src) for the .c file that uses the
CREATE_TRACE_POINTS macro, as the trace point macro magic headers
require it to find the TP header. Other files just need "foo.h", or
<trace/events/foo.h> if it's in the generic location.

-- Steve

2012-11-30 13:42:40

by Borislav Petkov

[permalink] [raw]
Subject: Re: [PATCH 1/3] aerdrv: Trace Event for AER

On Fri, Nov 30, 2012 at 06:39:11AM -0500, Steven Rostedt wrote:
> On Fri, 2012-11-30 at 11:53 +0100, Borislav Petkov wrote:
> > On Thu, Nov 29, 2012 at 08:51:19PM -0500, Steven Rostedt wrote:
> > > > include/ras/aer_event.h | 77 +++++++++++++++++++++++++++++++++++++++++++++++
> > >
> > > Is there a reason this header is here? Egad, I never noticed the
> > > ras_event.h that is there. This include/ras directory was created for
> > > the sole purpose of trace events! This is not the way to do this.
> >
> > Well, the idea for the ras event was to be able to use it in multiple
> > places. It is currently used only by EDAC but it could be that memory
> > errors could be reported by other agents which would reuse that TP.
> >
>
> If it's generic, then place it into the include/trace/events directory,
> the you don't need to have the TRACE_INCLUDE_PATH as that is the default
> path the macros will use.

Hmm, so I'm thinking maybe we should add a ras.h header there which
contains all RAS TPs.

> > > Please look at the sample in samples/trace_events/
> > >
> > > The proper way is to keep the header by the driver. Then you can simply
> > > include the header with "aer_event.h".
> > >
> > > But to have the macro magic work, you need to modify the Makefile to
> > > have something like:
> > >
> > > CFLAGS_aerdrv_errprint.o = -I$(src)
> >
> > So I'm guessing that every .c file including the TP should also -I
> > include the TP definition header wherever it is. Is that agreeable?
>
> You only need the -I$(src) for the .c file that uses the
> CREATE_TRACE_POINTS macro, as the trace point macro magic headers
> require it to find the TP header.

This is done like this from EDAC's single usage site:

#define CREATE_TRACE_POINTS
#define TRACE_INCLUDE_PATH ../../include/ras
#include <ras/ras_event.h>

This is in <drivers/edac/edac_mc.c> and it doesn't to "-I$(src)" in the
edac Makefile.

> Other files just need "foo.h", or <trace/events/foo.h> if it's in the
> generic location.

So, it sounds to me like we should we move all RAS-specific tracepoints
to <trace/events/ras.h> and then in each usage site do:

#define CREATE_TRACE_POINTS
#include <trace/events/ras.h>

Correct?

FWIW, it looks neat and clean to me that way.

Thanks.

--
Regards/Gruss,
Boris.

2012-11-30 13:53:56

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH 1/3] aerdrv: Trace Event for AER

On Fri, 2012-11-30 at 14:42 +0100, Borislav Petkov wrote:

> So, it sounds to me like we should we move all RAS-specific tracepoints
> to <trace/events/ras.h> and then in each usage site do:

Note, the CREATE_TRACE_POINTS must only be done in one location. Not
every place. It creates the code that does the work to make the
tracepoints show up in /debug/tracing/events/* as well as the callback
code and other such things. If you define it in more than one .c file,
then you will have linker issues due to the functions being created more
than once.

>
> #define CREATE_TRACE_POINTS
> #include <trace/events/ras.h>
>
> Correct?

That's the default way to do things.

>
> FWIW, it looks neat and clean to me that way.

Yep, that's why it's default ;-)

-- Steve

2012-11-30 17:36:40

by Borislav Petkov

[permalink] [raw]
Subject: Re: [PATCH 1/3] aerdrv: Trace Event for AER

On Fri, Nov 30, 2012 at 08:53:51AM -0500, Steven Rostedt wrote:
> On Fri, 2012-11-30 at 14:42 +0100, Borislav Petkov wrote:
>
> > So, it sounds to me like we should we move all RAS-specific tracepoints
> > to <trace/events/ras.h> and then in each usage site do:
>
> Note, the CREATE_TRACE_POINTS must only be done in one location. Not
> every place. It creates the code that does the work to make the
> tracepoints show up in /debug/tracing/events/* as well as the callback
> code and other such things. If you define it in more than one .c file,
> then you will have linker issues due to the functions being created more
> than once.
>
> >
> > #define CREATE_TRACE_POINTS
> > #include <trace/events/ras.h>
> >
> > Correct?
>
> That's the default way to do things.

Ok, cool.

Lance, care to move the TP to a new header called
include/trace/events/ras.h in your next iteration of the patches?

I'll later move the mc_event TP there too and drop the RAS-specific TP
header.

Thanks.

--
Regards/Gruss,
Boris.

2012-11-30 18:19:50

by Ortiz, Lance E

[permalink] [raw]
Subject: RE: [PATCH 1/3] aerdrv: Trace Event for AER


> Ok, cool.
>
> Lance, care to move the TP to a new header called
> include/trace/events/ras.h in your next iteration of the patches?

Will do.

Lance


????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?