- 31 5月, 2013 1 次提交
-
-
由 Lance Ortiz 提交于
The following warning was seen on 3.9 when a corrected PCIe error was being handled by the AER subsystem. WARNING: at .../drivers/pci/search.c:214 pci_get_dev_by_id+0x8a/0x90() This occurred because a call to pci_get_domain_bus_and_slot() was added to cper_print_pcie() to setup for the call to cper_print_aer(). The warning showed up because cper_print_pcie() is called in an interrupt context and pci_get* functions are not supposed to be called in that context. The solution is to move the cper_print_aer() call out of the interrupt context and into aer_recover_work_func() to avoid any warnings when calling pci_get* functions. Signed-off-by: NLance Ortiz <lance.ortiz@hp.com> Acked-by: NBorislav Petkov <bp@suse.de> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 27 3月, 2013 1 次提交
-
-
由 Chen Gong 提交于
In Table 18-289, ACPI5.0 SPEC, the error data length in CPER Generic Error Data Entry can be 0, which means this generic error data entry can have only one header. So fix the check conditon for it. Signed-off-by: NChen Gong <gong.chen@linux.intel.com> Reviewed-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 04 1月, 2013 1 次提交
-
-
由 Lance Ortiz 提交于
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 a PCIe error is reported over the AER interface. The trace event was added to both the interrupt based aer path and the firmware first path. Signed-off-by: NLance Ortiz <lance.ortiz@hp.com> Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com> Acked-by: NBoris Petkov <bp@alien8.de> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 30 3月, 2012 1 次提交
-
-
由 Jiang Liu 提交于
The function apei_estatus_print() and apei_estatus_check() forget to move ahead the gdata pointer when dealing with multiple generic error data sections. Signed-off-by: NJiang Liu <jiang.liu@huawei.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 22 3月, 2011 1 次提交
-
-
由 Huang Ying 提交于
The AER error information printing support is implemented in drivers/pci/pcie/aer/aer_print.c. So some string constants, functions and macros definitions can be re-used without being exported. The original PCIe AER error information printing function is not re-used directly because the overall format is quite different. And changing the original printing format may make some original users' scripts broken. Signed-off-by: NHuang Ying <ying.huang@intel.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: Zhang Yanmin <yanmin.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 14 12月, 2010 1 次提交
-
-
由 Huang Ying 提交于
In APEI, Hardware error information reported by firmware to Linux kernel is in the data structure of APEI generic error status (struct acpi_hes_generic_status). While now printk is used by Linux kernel to report hardware error information to user space. So, this patch adds printing support for the data structure, so that the corresponding hardware error information can be reported to user space via printk. PCIe AER information printing is not implemented yet. Will refactor the original PCIe AER information printing code to avoid code duplicating. The output format is as follow: <error record> := APEI generic hardware error status severity: <integer>, <severity string> section: <integer>, severity: <integer>, <severity string> flags: <integer> <section flags strings> fru_id: <uuid string> fru_text: <string> section_type: <section type string> <section data> <severity string>* := recoverable | fatal | corrected | info <section flags strings># := [primary][, containment warning][, reset][, threshold exceeded]\ [, resource not accessible][, latent error] <section type string> := generic processor error | memory error | \ PCIe error | unknown, <uuid string> <section data> := <generic processor section data> | <memory section data> | \ <pcie section data> | <null> <generic processor section data> := [processor_type: <integer>, <proc type string>] [processor_isa: <integer>, <proc isa string>] [error_type: <integer> <proc error type strings>] [operation: <integer>, <proc operation string>] [flags: <integer> <proc flags strings>] [level: <integer>] [version_info: <integer>] [processor_id: <integer>] [target_address: <integer>] [requestor_id: <integer>] [responder_id: <integer>] [IP: <integer>] <proc type string>* := IA32/X64 | IA64 <proc isa string>* := IA32 | IA64 | X64 <processor error type strings># := [cache error][, TLB error][, bus error][, micro-architectural error] <proc operation string>* := unknown or generic | data read | data write | \ instruction execution <proc flags strings># := [restartable][, precise IP][, overflow][, corrected] <memory section data> := [error_status: <integer>] [physical_address: <integer>] [physical_address_mask: <integer>] [node: <integer>] [card: <integer>] [module: <integer>] [bank: <integer>] [device: <integer>] [row: <integer>] [column: <integer>] [bit_position: <integer>] [requestor_id: <integer>] [responder_id: <integer>] [target_id: <integer>] [error_type: <integer>, <mem error type string>] <mem error type string>* := unknown | no error | single-bit ECC | multi-bit ECC | \ single-symbol chipkill ECC | multi-symbol chipkill ECC | master abort | \ target abort | parity error | watchdog timeout | invalid address | \ mirror Broken | memory sparing | scrub corrected error | \ scrub uncorrected error <pcie section data> := [port_type: <integer>, <pcie port type string>] [version: <integer>.<integer>] [command: <integer>, status: <integer>] [device_id: <integer>:<integer>:<integer>.<integer> slot: <integer> secondary_bus: <integer> vendor_id: <integer>, device_id: <integer> class_code: <integer>] [serial number: <integer>, <integer>] [bridge: secondary_status: <integer>, control: <integer>] <pcie port type string>* := PCIe end point | legacy PCI end point | \ unknown | unknown | root port | upstream switch port | \ downstream switch port | PCIe to PCI/PCI-X bridge | \ PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \ root complex event collector Where, [] designate corresponding content is optional All <field string> description with * has the following format: field: <integer>, <field string> Where value of <integer> should be the position of "string" in <field string> description. Otherwise, <field string> will be "unknown". All <field strings> description with # has the following format: field: <integer> <field strings> Where each string in <fields strings> corresponding to one set bit of <integer>. The bit position is the position of "string" in <field strings> description. For more detailed explanation of every field, please refer to UEFI specification version 2.3 or later, section Appendix N: Common Platform Error Record. Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 20 5月, 2010 1 次提交
-
-
由 Huang Ying 提交于
CPER stands for Common Platform Error Record, it is the hardware error record format used to describe platform hardware error by various APEI tables, such as ERST, BERT and HEST etc. For more information about CPER, please refer to Appendix N of UEFI Specification version 2.3. This patch mainly includes the data structure difinition header file used by other files. Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-