About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / PCI / pcieaer-howto.txt

Custom Search

Based on kernel version 4.8. Page generated on 2016-10-06 23:18 EST.

1	   The PCI Express Advanced Error Reporting Driver Guide HOWTO
2			T. Long Nguyen	<tom.l.nguyen@intel.com>
3			Yanmin Zhang	<yanmin.zhang@intel.com>
4					07/29/2006
7	1. Overview
9	1.1 About this guide
11	This guide describes the basics of the PCI Express Advanced Error
12	Reporting (AER) driver and provides information on how to use it, as
13	well as how to enable the drivers of endpoint devices to conform with
14	PCI Express AER driver.
16	1.2 Copyright (C) Intel Corporation 2006.
18	1.3 What is the PCI Express AER Driver?
20	PCI Express error signaling can occur on the PCI Express link itself
21	or on behalf of transactions initiated on the link. PCI Express
22	defines two error reporting paradigms: the baseline capability and
23	the Advanced Error Reporting capability. The baseline capability is
24	required of all PCI Express components providing a minimum defined
25	set of error reporting requirements. Advanced Error Reporting
26	capability is implemented with a PCI Express advanced error reporting
27	extended capability structure providing more robust error reporting.
29	The PCI Express AER driver provides the infrastructure to support PCI
30	Express Advanced Error Reporting capability. The PCI Express AER
31	driver provides three basic functions:
33	-	Gathers the comprehensive error information if errors occurred.
34	-	Reports error to the users.
35	-	Performs error recovery actions.
37	AER driver only attaches root ports which support PCI-Express AER
38	capability.
41	2. User Guide
43	2.1 Include the PCI Express AER Root Driver into the Linux Kernel
45	The PCI Express AER Root driver is a Root Port service driver attached
46	to the PCI Express Port Bus driver. If a user wants to use it, the driver
47	has to be compiled. Option CONFIG_PCIEAER supports this capability. It
48	depends on CONFIG_PCIEPORTBUS, so pls. set CONFIG_PCIEPORTBUS=y and
51	2.2 Load PCI Express AER Root Driver
52	There is a case where a system has AER support in BIOS. Enabling the AER
53	Root driver and having AER support in BIOS may result unpredictable
54	behavior. To avoid this conflict, a successful load of the AER Root driver
55	requires ACPI _OSC support in the BIOS to allow the AER Root driver to
56	request for native control of AER. See the PCI FW 3.0 Specification for
57	details regarding OSC usage. Currently, lots of firmwares don't provide
58	_OSC support while they use PCI Express. To support such firmwares,
59	forceload, a parameter of type bool, could enable AER to continue to
60	be initiated although firmwares have no _OSC support. To enable the
61	walkaround, pls. add aerdriver.forceload=y to kernel boot parameter line
62	when booting kernel. Note that forceload=n by default.
64	nosourceid, another parameter of type bool, can be used when broken
65	hardware (mostly chipsets) has root ports that cannot obtain the reporting
66	source ID. nosourceid=n by default.
68	2.3 AER error output
69	When a PCI-E AER error is captured, an error message will be outputted to
70	console. If it's a correctable error, it is outputted as a warning.
71	Otherwise, it is printed as an error. So users could choose different
72	log level to filter out correctable error messages.
74	Below shows an example:
75	0000:50:00.0: PCIe Bus Error: severity=Uncorrected (Fatal), type=Transaction Layer, id=0500(Requester ID)
76	0000:50:00.0:   device [8086:0329] error status/mask=00100000/00000000
77	0000:50:00.0:    [20] Unsupported Request    (First)
78	0000:50:00.0:   TLP Header: 04000001 00200a03 05010000 00050100
80	In the example, 'Requester ID' means the ID of the device who sends
81	the error message to root port. Pls. refer to pci express specs for
82	other fields.
85	3. Developer Guide
87	To enable AER aware support requires a software driver to configure
88	the AER capability structure within its device and to provide callbacks.
90	To support AER better, developers need understand how AER does work
91	firstly.
93	PCI Express errors are classified into two types: correctable errors
94	and uncorrectable errors. This classification is based on the impacts
95	of those errors, which may result in degraded performance or function
96	failure.
98	Correctable errors pose no impacts on the functionality of the
99	interface. The PCI Express protocol can recover without any software
100	intervention or any loss of data. These errors are detected and
101	corrected by hardware. Unlike correctable errors, uncorrectable
102	errors impact functionality of the interface. Uncorrectable errors
103	can cause a particular transaction or a particular PCI Express link
104	to be unreliable. Depending on those error conditions, uncorrectable
105	errors are further classified into non-fatal errors and fatal errors.
106	Non-fatal errors cause the particular transaction to be unreliable,
107	but the PCI Express link itself is fully functional. Fatal errors, on
108	the other hand, cause the link to be unreliable.
110	When AER is enabled, a PCI Express device will automatically send an
111	error message to the PCIe root port above it when the device captures
112	an error. The Root Port, upon receiving an error reporting message,
113	internally processes and logs the error message in its PCI Express
114	capability structure. Error information being logged includes storing
115	the error reporting agent's requestor ID into the Error Source
116	Identification Registers and setting the error bits of the Root Error
117	Status Register accordingly. If AER error reporting is enabled in Root
118	Error Command Register, the Root Port generates an interrupt if an
119	error is detected.
121	Note that the errors as described above are related to the PCI Express
122	hierarchy and links. These errors do not include any device specific
123	errors because device specific errors will still get sent directly to
124	the device driver.
126	3.1 Configure the AER capability structure
128	AER aware drivers of PCI Express component need change the device
129	control registers to enable AER. They also could change AER registers,
130	including mask and severity registers. Helper function
131	pci_enable_pcie_error_reporting could be used to enable AER. See
132	section 3.3.
134	3.2. Provide callbacks
136	3.2.1 callback reset_link to reset pci express link
138	This callback is used to reset the pci express physical link when a
139	fatal error happens. The root port aer service driver provides a
140	default reset_link function, but different upstream ports might
141	have different specifications to reset pci express link, so all
142	upstream ports should provide their own reset_link functions.
144	In struct pcie_port_service_driver, a new pointer, reset_link, is
145	added.
147	pci_ers_result_t (*reset_link) (struct pci_dev *dev);
149	Section provides more detailed info on when to call
150	reset_link.
152	3.2.2 PCI error-recovery callbacks
154	The PCI Express AER Root driver uses error callbacks to coordinate
155	with downstream device drivers associated with a hierarchy in question
156	when performing error recovery actions.
158	Data struct pci_driver has a pointer, err_handler, to point to
159	pci_error_handlers who consists of a couple of callback function
160	pointers. AER driver follows the rules defined in
161	pci-error-recovery.txt except pci express specific parts (e.g.
162	reset_link). Pls. refer to pci-error-recovery.txt for detailed
163	definitions of the callbacks.
165	Below sections specify when to call the error callback functions.
167 Correctable errors
169	Correctable errors pose no impacts on the functionality of
170	the interface. The PCI Express protocol can recover without any
171	software intervention or any loss of data. These errors do not
172	require any recovery actions. The AER driver clears the device's
173	correctable error status register accordingly and logs these errors.
175 Non-correctable (non-fatal and fatal) errors
177	If an error message indicates a non-fatal error, performing link reset
178	at upstream is not required. The AER driver calls error_detected(dev,
179	pci_channel_io_normal) to all drivers associated within a hierarchy in
180	question. for example,
181	EndPoint<==>DownstreamPort B<==>UpstreamPort A<==>RootPort.
182	If Upstream port A captures an AER error, the hierarchy consists of
183	Downstream port B and EndPoint.
185	A driver may return PCI_ERS_RESULT_CAN_RECOVER,
187	whether it can recover or the AER driver calls mmio_enabled as next.
189	If an error message indicates a fatal error, kernel will broadcast
190	error_detected(dev, pci_channel_io_frozen) to all drivers within
191	a hierarchy in question. Then, performing link reset at upstream is
192	necessary. As different kinds of devices might use different approaches
193	to reset link, AER port service driver is required to provide the
194	function to reset link. Firstly, kernel looks for if the upstream
195	component has an aer driver. If it has, kernel uses the reset_link
196	callback of the aer driver. If the upstream component has no aer driver
197	and the port is downstream port, we will perform a hot reset as the
198	default by setting the Secondary Bus Reset bit of the Bridge Control
199	register associated with the downstream port. As for upstream ports,
200	they should provide their own aer service drivers with reset_link
201	function. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER and
202	reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes
203	to mmio_enabled.
205	3.3 helper functions
207	3.3.1 int pci_enable_pcie_error_reporting(struct pci_dev *dev);
208	pci_enable_pcie_error_reporting enables the device to send error
209	messages to root port when an error is detected. Note that devices
210	don't enable the error reporting by default, so device drivers need
211	call this function to enable it.
213	3.3.2 int pci_disable_pcie_error_reporting(struct pci_dev *dev);
214	pci_disable_pcie_error_reporting disables the device to send error
215	messages to root port when an error is detected.
217	3.3.3 int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev);
218	pci_cleanup_aer_uncorrect_error_status cleanups the uncorrectable
219	error status register.
221	3.4 Frequent Asked Questions
223	Q: What happens if a PCI Express device driver does not provide an
224	error recovery handler (pci_driver->err_handler is equal to NULL)?
226	A: The devices attached with the driver won't be recovered. If the
227	error is fatal, kernel will print out warning messages. Please refer
228	to section 3 for more information.
230	Q: What happens if an upstream port service driver does not provide
231	callback reset_link?
233	A: Fatal error recovery will fail if the errors are reported by the
234	upstream ports who are attached by the service driver.
236	Q: How does this infrastructure deal with driver that is not PCI
237	Express aware?
239	A: This infrastructure calls the error callback functions of the
240	driver when an error happens. But if the driver is not aware of
241	PCI Express, the device might not report its own errors to root
242	port.
244	Q: What modifications will that driver need to make it compatible
245	with the PCI Express AER Root driver?
247	A: It could call the helper functions to enable AER in devices and
248	cleanup uncorrectable status register. Pls. refer to section 3.3.
251	4. Software error injection
253	Debugging PCIe AER error recovery code is quite difficult because it
254	is hard to trigger real hardware errors. Software based error
255	injection can be used to fake various kinds of PCIe errors.
257	First you should enable PCIe AER software error injection in kernel
258	configuration, that is, following item should be in your .config.
262	After reboot with new kernel or insert the module, a device file named
263	/dev/aer_inject should be created.
265	Then, you need a user space tool named aer-inject, which can be gotten
266	from:
267	    http://www.kernel.org/pub/linux/utils/pci/aer-inject/
269	More information about aer-inject can be found in the document comes
270	with its source code.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.