This patch includes PCIEAER-HOWTO.txt, which describes how the PCI
Express Advanced Error Reporting Root driver works.
Signed-off-by: T. Long Nguyen <[EMAIL PROTECTED]>
--------------------------------------------------------------------
diff -urpN linux-2.6.11-rc5/Documentation/PCIEAER-HOWTO.txt
patch-2.6.11-rc5-aerc3-split1/Documentation/PCIEAER-HOWTO.txt
--- linux-2.6.11-rc5/Documentation/PCIEAER-HOWTO.txt 1969-12-31
19:00:00.000000000 -0500
+++ patch-2.6.11-rc5-aerc3-split1/Documentation/PCIEAER-HOWTO.txt
2005-03-11 10:25:21.000000000 -0500
@@ -0,0 +1,712 @@
+ The PCI Express Advanced Error Reporting Root Driver Guide HOWTO
+ T. Long Nguyen <[EMAIL PROTECTED]>
+ 02/23/2005
+
+1. About this guide
+
+This guide describes the basics of the PCI Express Advanced Error
+Reporting (AER) Root driver and provides information on how to enable
+the drivers of AER endpoint devices to register/un-register with PCI
+Express Root AER driver.
+
+2. Copyright © Intel Corporation 2005.
+
+3. What is the PCI Express AER Root Driver?
+
+PCI Express error signaling can occur on the PCI Express link itself
+or on behalf of transactions initiated on the link. PCI Express
+defines two error reporting paradigms: the baseline capability and
+the Advanced Error Reporting capability. The baseline capability is
+required of all PCI Express components providing a minimum defined
+set of error reporting requirements. Advanced Error Reporting
+capability is implemented with a PCI Express advanced error reporting
+extended capability structure providing more robust error reporting.
+
+The PCI Express AER Root driver provides the mechanism to support PCI
+Express Advanced Error Reporting capability. The PCI Express AER Root
+driver provides three basic functions:
+
+- A mechanism to allow a driver of a PCI Express component to
+ register/un-register its AER aware callback handle with the
+ PCI Express AER Root driver. This mechanism is provided as
+ an option to allow the PCI Express AER Root driver to query
+ the PCI Express component device driver to determine more
+ precisely which error and what severity occurred.
+
+- A mechanism to process the error reporting message detected
+ by Root Ports, and report the errors to user.
+
+4. Why Use the PCI Express AER Root Driver?
+
+In a PCI Express-aware system, a PCI Express component in a hierarchy
+associated with the Root Port can send an error reporting message
+to the Root Port. The Root Port, upon receiving an error reporting
+message, internally processes and logs the error message in its PCI
+Express capability structure. Error information being logged includes
+storing the error reporting agent's requestor ID into the Error
+Source Identification Registers and setting the error bits of the
+Root Error Status Register accordingly. If AER error reporting is
+enabled in Root Error Command Register, the Root Port generates an
+interrupt if an error is detected.
+
+In existing Linux kernels, 2.4.x and 2.6.x, there is no root service
+driver available to manage the PCI Express advanced error reporting
+extended capability structure. If an error is detected by the Root
+Port, the baseline capability, as described above, therefore must
+be provided by platform hardware to provide the platform-specific
+system with minimum defined error reporting requirements. Such a
+platform-specific system may have BIOS not only configure the Root
+Control Register of the Root Ports' PCI Express capability structure
+to generate the system error accordingly but also handle error
+reporting messages. Using platform-specific BIOS to handle system
+error reporting has three key issues:
+
+- Inability to coordinate with the downstream device drivers
+ to determine more precisely which error and what severity.
+
+- Inability to reset the downstream links while handling fatal
+ error recovery.
+
+- Platform-specific dependency.
+
+To provide a solution to these issues requires the PCI Express AER
+Root driver that provides:
+
+- A mechanism for the OS and application to determine if a fatal
+ error is fatal to the system, OS, or application increasing
+ uptime.
+
+- A mechanism to notify the downstream device drivers if errors
+ occurred.
+
+- A mechanism to dynamically perform error recovery actions
+ based on configuration options.
+
+- Platform-specific independence.
+
+5. Including the PCI Express AER Root Driver into the Linux Kernel
+
+The PCI Express AER Root driver is a Root Port service driver attached
+to the PCI Express Port Bus driver. Its service must be registered
+with the PCI Express Port Bus driver and users are required to include
+the PCI Express Port Bus driver in the kernel (refer to
+PCIEBUS-HOWTO.txt). Once the kernel config CONFIG_PCIEPORTBUS is
+included, the PCI Express AER Root driver is automatically included
+as a kernel driver by default (CONFIG_PCIEAER = Y). Users may disable
+the PCI Express AER driver by clearing CONFIG_PCIEAER.
+
+Note that there is a case where a system has AER support in BIOS.
+Enabling the AER Root driver and having AER support in BIOS may
+result unpredictable behavior. To avoid this conflict, a successful
+load of the AER Root driver requires ACPI _OSC support in the BIOS to
+allow the AER Root driver to request for native control of AER. See
+the PCI FW 3.0 Specification for details regarding OSC usage.
+
+6. Enabling AER Aware Support in PCI Express Device Driver
+
+To enable AER aware support requires a software driver to configure
+the AER capability structure within its device, to initialize its AER
+aware callback handle and to call pcie_aer_register. Sections 6.1,
+6.2, and 6.3 describe how to enable AER aware support in details.
+
+6.1 Calling pcie_aer_register
+
+The PCI Express AER Root driver defines a register-callback
+mechanism to provide AER aware drivers of PCI Express components
+to register their callback handles with the PCI Express AER Root
+driver. The PCI Express AER Root driver uses these callback handles
+to coordinate with downstream AER aware drivers to provide not only
+more robust error reporting but also the ability to reset the link,
+in a hierarchy associated with the Root Port, while handling fatal
+error recovery.
+
+To register AER callback handle requires an AER aware driver of PCI
+Express component to call pcie_aer_register. Calling pcie_aer_register
+is provided as an option instead of a requirement to make sure that
+the PCI Express AER Root driver works with existing PCI Express
+drivers. However, this patch highly recommends that a software driver
+of PCI Express component should call pcie_aer_register because
+calling pcie_aer_register poses no impact on its behavior. The
+following reasons explain why calling pcie_aer_register is safe and
+recommended.
+
+- In a PCI Express aware kernel, the PCI Express AER Root
+ driver uses register-callback handle to coordinate with an
+ AER aware driver of PCI Express component when an error
+ occurs. Such coordination enables an AER aware driver to
+ clear corresponding error status, to recover any unreliable
+ transactions if required, and to report more precisely which
+ error and what severity to the PCI Express AER Root driver.
+
+- In a non-PCI Express-aware kernel, pcie_aer_register returns
+ non-zero immediately as an indicator to tell the driver that
+ BIOS/FW is in control.
+
+Note that pcie_aer_unregister is also provided to allow an AER
+aware driver to undo the effect of calling pcie_aer_register.
+Calling pcie_aer_unregister is required when an AER aware driver
+is unloaded.
+
+"AER assumes only one AER aware driver will register per device ID"..
+
+6.2 Configure PCI Express Component to Report Errors
+
+PCI Express errors are classified into two types: correctable errors
+and uncorrectable errors. This classification is based on the impacts
+of those errors, which may result in function failure or in degraded
+performance.
+
+Correctable errors pose no impacts on the functionality of the
+interface. The PCI Express protocol can recover without any software
+intervention or any loss of data. These errors are detected and
+corrected by hardware. Unlike correctable errors, uncorrectable
+errors impact functionality of the interface. Uncorrectable errors
+can cause a particular transaction or a particular PCI Express link
+to be unreliable. Depending on those error conditions, uncorrectable
+errors are further classified into fatal errors and non-fatal errors.
+Non-fatal errors cause the particular transaction to be unreliable,
+but the PCI Express link itself is fully functional. Fatal errors, on
+the other hand, cause the link to be unreliable.
+
+Because selecting specific correctable/uncorrectable errors to report
+to Root Port is device implementation specific, an AER aware driver
+of PCI Express component is responsible for configuring its device not
+only to mask specific correctable/uncorrectable errors but also to
+select whether an individual uncorrectable error is reported as a
+non-fatal or fatal error.
+
+Note that the errors as described above are related to the PCI Express
+hierarchy and links. These errors do not include any device specific
+errors because device specific errors will still get sent directly to
+the device driver.
+
+6.3 Provide AER Service Callback Handle
+
+As described in above paragraph, an AER aware driver must provide its
+AER aware callback handle by calling pcie_aer_register. The data
+structure of callback handle is defined in section 7. The PCI Express
+AER Root driver uses callback handle to notify an AER aware driver
+associated with an agent, which sends an error message to the Root
+Port. Because the Root Port reports error of either correctable or
+uncorrectable, the PCI Express AER Root driver notifies an AER aware
+driver with either AER_CORRECTABLE or AER_UNCORRECTABLE. An AER aware
+driver is responsible for clearing the error status within its device
+and reporting back to the PCI Express AER Root driver with appropriate
+eror status and error type.
+
+If the Root Port detected a correctable error, the PCI Express AER
+Root driver notifies an AER aware driver of the agent, which sent
+an error, to determine more precisely which correctable error. No
+other actions are necessary because the PCI Express protocol can
+recover without any software intervention or any loss of data. An
+AER aware driver is responsible for clearing its correctable error
+status within its device and reporting back to the PCI Express AER
+Root driver with the correctable error status.
+
+If the Root Port detected an uncorrectable error, the PCI Express AER
+Root driver notifies an AER aware driver of the agent, which sent an
+error, to determine more precisely which uncorrectable error and what
+severity (non-fatal/fatal) occurred. In addition to notify, the PCI
+Express AER Root driver calls an AER aware driver to query for any
+specific TLP header associated with non-fatal error because some
+non-fatal errors may have associated TLP header and some may not.
+An AER aware driver is responsible for clearing its uncorrectable
+error status within its device, recovering any unreliable transactions
+and reporting back to the PCI Express AER Root driver with the
+uncorrectable error status and AER_NONFATAL/AER_FATAL type.
+
+If the error information returned from an AER aware driver indicates
+a fatal severity, the AER Root driver may attempt to return the link,
+where an AER aware agent is point-to-point connected, to reliable
+operation by resetting the link. Depending on the link position in a
+hierarchy associated with the Root Port, the PCI Express AER Root
+driver may invoke AER aware drivers of downstream devices associated
+with this link hierarchy to abort their operations before resetting
+the link and restart their operations after returning the link to
+reliable. This is one of the key advantages of why software drivers
+of PCI Express components should be AER aware.
+
+Note that the link reset, called the Training Control Reset or hot
+reset, is performed by an upstream device to force a reset of all
+downstream devices. A bridge must propagate hot reset onto all
+downstream links. A downstream device can optionally use hot reset
+to reset its internal logic. The mechanism of hot reset is device
+implementation specific. If the upstream device of the link does not
+support hot reset or the software driver of upstream device is not
+AER aware, there is no attempt to return the link to reliable.
+
+6.4 Sample Code
+
+Below is the sample code of how a device driver registers its AER
+callback handle with the PCI Express AER driver.
+
+static int generic_aer_notify(u16 requestor_id, union aer_error *error)
+{
+ struct pci_dev *dev = (struct pci_dev*)host->dev;
+ u32 status;
+ u16 reg16;
+ int pos;
+
+ if (requestor_id != ((dev->bus->number << 8) | dev->devfn))
+ return -EINVAL;
+
+ if (error->type == AER_CORRECTABLE) {
+ pci_read_config_dword(dev,
+ CORRECTABLE_ERROR_STATUS_REG, &status);
+ pci_write_config_dword(dev,
+ CORRECTABLE_ERROR_STATUS_REG, status);
+ if (!(status & CORRECTABLE_ERROR_MASK_REG))
+ return -EINVAL;
+
+ /*
+ * AER Root driver needs this info to determine more
+ * precisely which error and what severity occurred.
+ */
+ error->source.status = status;
+
+ /*
+ * DEVICE SPECIFIC FIXUP
+ */
+ } else {
+ pci_read_config_dword(dev,
+ UNCORRECTABLE_ERROR_STATUS_REG, &status);
+ pci_write_config_dword(dev,
+ UNCORRECTABLE_ERROR_STATUS_REG, status);
+ if (!(status & UNCORRECTABLE_ERROR_MASK_REG))
+ return -EINVAL;
+
+ /*
+ * AER Root driver needs this info to determine more
+ * precisely which error and what severity occurred.
+ */
+ error->source.status = status;
+ if (status & UNCORRECTABLE_ERROR_SEVERITY_MASK)
+ error->source.type = AER_FATAL;
+ else
+ error->source.type = AER_NONFATAL;
+
+ /*
+ * DEVICE SPECIFIC FIXUP
+ */
+ }
+
+ /* Clean up PCIE capability's device status */
+ pos = pci_find_capability(dev, PCI_CAP_ID_EXP);
+ pci_read_config_word(dev, pos +
+ PCIE_CAP_DEVICE_STATUS_REG_OFF, ®16);
+ pci_write_config_word(dev, pos +
+ PCIE_CAP_DEVICE_STATUS_REG_OFF, reg16);
+
+ return 0;
+}
+
+static int generic_aer_get_header(unsigned short requestor_id,
+ union aer_error *error, struct header_log_regs *log)
+{
+ struct pci_dev *dev = (struct pci_dev*)host->dev;
+
+ if (error->type == AER_CORRECTABLE ||
+ !(error->source.status & TLP_MASKS))
+ return -EINVAL;
+
+ pci_read_config_dword(dev, HEADER_LOG_REG, &log->dw0);
+ pci_read_config_dword(dev, HEADER_LOG_REG + 4, &log->dw1);
+ pci_read_config_dword(dev, HEADER_LOG_REG + 8, &log->dw2);
+ pci_read_config_dword(dev, HEADER_LOG_REG + 12, &log->dw3);
+
+ return 0;
+}
+
+
+static int generic_aer_link_rec_prepare(unsigned short requestor_id)
+{
+ /*
+ * Link Recovery Prepare. Stop all transactions
+ * DEVICE SPECIFIC FIXUP
+ */
+
+ return 0;
+}
+
+static int generic_aer_link_rec_restart(unsigned short requestor_id)
+{
+ /*
+ * Link Recovery Restart. Transaction Retry.
+ * DEVICE SPECIFIC FIXUP
+ */
+
+ return 0;
+}
+
+struct pcie_aer_handle generic_aer_handle = {
+ .notify = generic_aer_notify,
+ .get_header = generic_aer_get_header,
+ .link_rec_prepare = generic_aer_link_rec_prepare,
+ .link_rec_restart = generic_aer_link_rec_restart
+};
+
+int hw_aer_register(struct pci_dev *dev)
+{
+ int status;
+
+ /* AER Init */
+ hw_aer_enable(dev);
+
+ /* Register with AER Root driver */
+ if ((status = pcie_aer_register(dev, &generic_aer_handle)))
+ hw_aer_disable(dev);
+
+ return status;
+}
+
+void hw_aer_unregister(void)
+{
+ struct pci_dev *dev = (struct pci_dev*)host->dev;
+ unsigned short id;
+
+ id = (dev->bus->number << 8) | dev->devfn;
+
+ /* Unregister with AER Root driver */
+ pcie_aer_unregister(id);
+}
+
+static int __devinit hw_pci_probe(struct pci_dev *dev,
+ const struct pci_device_id *id )
+{
+ /*
+ * Hardware Init
+ */
+
+ hw_aer_register(dev);
+ return 0;
+}
+
+static void __exit hw_exit_cleanup(void)
+{
+ hw_aer_unregister();
+
+ /*
+ * Hardware Cleanup
+ */
+}
+
+7. Data Structure of Callback Handle
+
+The PCI Express AER Root driver defines a data structure, named struct
+pcie_aer_handle, which contains five callback routines. The device
+driver of PCI Express component provides the callback routines when
+calling pcie_aer_register. The PCI Express AER Root driver uses the
+callback routines to notify the device driver if its device detects
+an error and sends an error message to Root Port. Depending on an
+error message, the PCI Express AER Root driver may call an AER aware
+driver to query for more error information or possibly to reset the
+link to return to reliable operation.
+
+The data structure of pcie_aer_handle is defined as below:
+
+struct pcie_aer_handle {
+
+ int (*notify) (u16 requestor_id, union aer_error *error);
+
+ int (*get_header) (u16 requestor_id, union aer_error *error,
+ struct header_log_regs *log);
+
+ int (*link_rec_prepare) (u16 requestor_id);
+
+ int (*link_rec_restart) (u16 requestor_id);
+
+ int (*link_reset) (u16 requestor_id);
+};
+
+With aer_error data structure is defined as:
+
+union aer_error {
+ unsigned int type;
+ struct {
+ unsigned int type;
+ unsigned int status;
+ }source;
+};
+
+- int (*notify) (u16 requestor_id, union aer_error *error)
+
+ An AER aware driver is required to provide this callback.
+ The PCI Express AER Root driver calls notify to inform an
+ AER aware driver that its device has detected an error and
+ sent the error reporting message to Root Port. An error
+ message can be either ERR_COR or ERR_UNCOR, which is further
+ categorized into either ERR_FATAL or ERR_NONFATAL. Because
+ these errors are device-specific and configured by an AER
+ aware driver, retrieving a precise error type requires the PCI
+ Express AER Root driver to call notify with error->type
+ set to either AER_CORRECTABLE or AER_UNCORRECTABLE. Once
+ being invoked, an AER aware driver requires returning
+ error->source.status and error->source.type. Refer to the
+ sample code in section 6.4.
+
+ In addition, an AER aware driver is responsible for clearing
+ its corresponding error status, recovering any unreliable
+ transactions if required, and returning its device to a
+ reliable state.
+
+- int (*get_header) (u16 requestor_id, union aer_error *error,
+ struct header_log_regs *log)
+
+ An AER aware driver is required to provide this callback.
+ The PCI Express AER Root driver calls get_header if an error
+ message is either ERR_FATAL or ERR_NONFATAL. Some of these
+ errors may have associated TLP header and some may not. The
+ PCI Express AER Root driver has no knowledge of whether TLP
+ header should be reported along with a detected error. Again,
+ it is the responsibility of an AER aware driver, once being
+ invoked, to indicate whether an error has an associated TLP
+ header. A return of zero indicates a param log pointer
+ containing valid TLP header. A return of nonzero is otherwise.
+
+- int (*link_rec_prepare) (u16 requestor_id)
+
+ An AER aware driver is required to provide this callback.
+ The PCI Express AER Root driver calls link_rec_prepare if and
+ only if it requires resetting the link in a hierarchy
+ associated with PCI Express Port, which detected and sent a
+ fatal error message to the Root Port. PCI Express Port can be
+ a Root Port itself, an Upstream Switch Port, or a Downstream
+ Switch Port. The PCI AER Root driver, before doing a hot reset
+ on PCI Express Port, informs AER aware driver of each
+ downstream PCI Express component in a hierarchy to abort all
+ currently in-progress transactions.
+
+- int (*link_rec_restart) (u16 requestor_id)
+
+ An AER aware driver is required to provide this callback.
+ The PCI Express AER Root driver calls link_rec_restart to
+ inform AER aware driver of each downstream PCI Express
+ component to retry all transactions aborted by the previous
+ link_rec_prepare call and any device initialization that may
+ be required due to the link reset.
+
+- int (*link_reset) (u16 requestor_id)
+
+ The PCI Express AER Root driver calls link_reset when the Root
+ Port detects a fatal error message, which was sent by a PCI
+ Express Port in a hierarchy associated with the Root Port.
+ Performing a hot reset on this PCI Express Port is necessary
+ in attempt of returning this Port to reliable operation (fatal
+ error recovery). Again note that the mechanism of hot reset is
+ device implementation specific. An AER aware driver is not
+ required to provide this callback if its PCI Express Port
+ hardware device does not support hot reset.
+
+ Note this callback is not required for an AER aware driver of
+ PCI Express endpoint device.
+
+8. APIs
+
+8.1 pcie_aer_register
+
+int pcie_aer_register(struct pci_dev*, struct pcie_aer_handle *handle)
+
+The PCI Express AER Root driver provides pcie_aer_register to allow
+a software driver of PCI Express component to register its AER
+callback handle. Note that this API is provided as an option to
+provide more robust error reporting. If PCI Express AER Root driver
+detects an error message sent by an agent, which does not AER
+callback handle in its driver, PCI Express AER Root driver will
+provide basic error reporting as described in section 6.
+
+8.2 pcie_aer_unregister
+
+void pcie_aer_unregister(unsigned short requestor_id)
+
+The PCI Express AER Root driver provides pcie_aer_unregister to allow
+a software driver of PCI Express component to undo the effect of
+calling pcie_aer_register. Note that a device driver should always
+call pcie_aer_unregister when it unloads.
+
+9. Error Reporting Data Structures
+
+PCI Express AER error reporting data structures are defined to
+consist of three components: Record Header, Platform PCIE Bus Error
+Info section and PCI Component Error Info section.
+
+Record Header contains generic information such as the record
+revision, the record length, the error severity, and the time stamp
+at which an error occurred.
+
+Platform PCIE Bus Error Info section provides the section length and
+the information of detected error. Note that the context of PCI
+Express error information is depending on whether an agent's software
+driver is AER aware or not.
+
+PCI Component Error Info section provides the section length and the
+PCI component information of an agent, which detects and sends an
+error message to Root Port. Such PCI component information includes
+bus number, device number and function number.
+
+9.1 Error Reporting Samples
+
+This patch provides two samples of how the PCI Express AER Root
+driver reports errors detected by Root Port. Since Root Port reports
+detected error as correctable or uncorrectable, obtaining specific
+error type requires the use of callback handle registered by an AER
+aware driver. If an AER aware driver of an agent, which sent an
+error to Root Port, has its callback handle registered, then the PCI
+Express AER Root driver will notify an AER aware driver to obtain
+specific error type. If not, then an error detected by Root Port is
+known as Unaccessible.
+
+9.1.1 Without Register Callback Handle
+
+Error Severity : Uncorrected
+Time Stamp : 2/16/2005 7:51:24
+PCIE Bus Error type : Unaccessible
+Unaccessible Received : Multiple
+Unregistered Agent ID : 0030
+VendorID=xxxxh, DeviceID=xxxxh, Bus=00h, Device=06h, Function=00h
+
+9.1.2 With Register Callback Handle
+
+Error Severity : Uncorrected (Non-Fatal)
+Time Stamp : 2/16/2005 7:51:24
+PCIE Bus Error type : Transaction Layer
+Poisoned TLP : Multiple
+Receiver ID : 0030
+VendorID=8086h, DeviceID=3599h, Bus=00h, Device=06h, Function=00h
+
+10. User Interface
+
+Interface, /sys/bus/pci_express/drivers/aer, is provided to enable
+user to interface with PCI Express AER Root driver. The description
+of the interface is defined as below:
+
+/sys/bus/pci_express/drivers/aer
+ |
+ |___ auto
+ |
+ |___ consume
+ |
+ |___ status
+ |
+ |___ verbose
+
+Option auto indicates whether user wants the PCI Express AER Root
+driver to write error reporting into /var/log/messages (ON) or to hold
+error logs in a system memory until user manually consumes these
+error logs (OFF). This option can be read or written. A read returns
+the auto mode and a write sets the auto mode. Auto mode is turned ON
+by default. Note that in an auto-off mode, the latest error log is
+consumed first while in an auto-on mode, an error log is automatically
+consumed and written into /var/log/messages.
+
+Option consume is valid only when auto mode is OFF. This option is
+read only. When auto mode is OFF, user can consume any detected error
+logs stored in a system memory one at a time (FILO). A read, such as
+cat consume, displays the error reporting in a full display or a raw
+binary display. This patch defines the maximum number of error logs
+stored in a system memory to EVENT_LOG_SIZE_MAX (100). If the number
+of error logs exceeds this limit, the user will start loosing error
+logs (oldest) if he doesn't consume.
+
+Option status allows user to display a AER hierarchy maintained by
+the PCI Express AER Root driver. A sample of AER hierarchy is shown as
+below:
+
+Root Port [0.2.4] Device List:
+ Bus 0, device 2, function 0:
+ Class 60400: PCI device 3595:8086
+ COR_ERR 0, NONFATAL_ERR 0, FATAL_ERR 0
+ Register Callbacks - Yes
+Root Port [0.5.5] Device List:
+ Bus 0, device 4, function 0:
+ Class 60400: PCI device 3597:8086
+ COR_ERR 0, NONFATAL_ERR 0, FATAL_ERR 0
+ Register Callbacks - Yes
+Root Port [0.6.6] Device List:
+ Bus 0, device 6, function 0:
+ Class 60400: PCI device 3599:8086
+ COR_ERR 0, NONFATAL_ERR 3, FATAL_ERR 0
+ Last Error Detected @ 2/16/2005 7:52:35 - Poisoned TLP
+ Register Callbacks - Yes
+ Bus 6, device 0, function 0:
+ Class ff0000: PCI device 5375:8086
+ COR_ERR 0, NONFATAL_ERR 0, FATAL_ERR 0
+ Register Callbacks - Yes
+
+Option verbose allows user to setup how error is reported. This
+option can be read or written. There are display options as below:
+
+1) Error reporting is displayed in a limited format. To select this
+option, user does "echo 1 > /sys/bus/pci_express/drivers/aer/verbose".
+The sample is shown below.
+
+Error Severity : Uncorrected (Non-Fatal)
+Time Stamp : 2/16/2005 7:51:24
+PCIE Bus Error type : Transaction Layer
+Poisoned TLP : Multiple
+Receiver ID : 0030
+VendorID=8086h, DeviceID=3599h, Bus=00h, Device=06h, Function=00h
+
+2) Error reporting is displayed in a full format. To select this
+option, user does "echo 2 > /sys/bus/pci_express/drivers/aer/verbose".
+The sample is shown below.
+
++------ RECORD HEADER -----+
+Revision : 00.03
+Error Severity : Uncorrected (Non-Fatal)
+Validation Bits : 0x2
+Record Length (bytes) : 0x78
+Time Stamp : 2/16/2005 7:52:14
++--------------------------+
++ SECTION #0 HEADER +
++--------------------------+
+Revision : 00.02
+Error Recovery Info : UnCorrected
+PCIE Bus Error type : Transaction Layer
+Poisoned TLP : Multiple
+Receiver ID : 0030
++--------------------------+
++ SECTION #1 HEADER +
++--------------------------+
+Revision : 00.02
+Error Recovery Info : UnCorrected
+VendorID=8086h, DeviceID=3599h, Bus=00h, Device=06h, Function=00h
+TLB Header:
+40005020 060001ff 1fda8000 00000000
+
+3) Error reporting is displayed in a raw binary dump format. To select
+option, user does "echo 3 > /sys/bus/pci_express/drivers/aer/verbose".
+The sample is shown below.
+
+00 00 00 00 00 00 00 00 03 00 00 02 78 00 00 00
+23 34 07 00 10 02 69 14 02 00 80 00 1c 00 00 00
+05 00 00 00 00 00 00 00 00 44 00 40 00 10 00 00
+30 00 00 00 02 00 80 00 44 00 00 00 22 00 00 00
+00 00 00 00 00 00 00 00 00 00 00 00 86 80 99 35
+00 04 06 00 06 00 00 00 00 00 00 00 00 00 00 00
+00 00 00 00 14 00 20 50 00 40 ff 02 00 06 00 80
+da 1f 00 00 00 00 00 00
+
+11. Frequent Asked Questions
+
+Q: What happens if a PCI Express device driver does not register its
+callback handle with the PCI Express AER Root driver?
+
+A: The PCI Express AER Root driver maintains a list of all registered
+callback handles. When an error is logged in the Root Port, the PCI
+Express AER Root driver reads an agent's requestor ID. If the
+requestor ID is not found in a list of all registered callback
+handles associated with this Root Port, a limited error reporting log
+is provided since specific error type is not accessible.
+
+Q: How does this infrastructure deal with driver that is not PCI
+Express aware?
+
+A: This infrastructure handles non-PCI Express aware driver the same
+way as handling driver that does not register its callback handle
+with the PCI Express AER Root driver.
+
+Q: What modifications will that driver need to make it compatible
+with the PCI Express AER Root driver?
+
+A: Please refer to section 6 above.
+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
