- 09 3月, 2012 2 次提交
-
-
由 Gavin Shan 提交于
There're 4 EEH operations that are covered by the dedicated RTAS call <ibm,set-eeh-option>: enable or disable EEH, enable MMIO and enable DMA. At early stage of system boot, the EEH would be tried to enable on PCI device related device node. MMIO and DMA for particular PE should be enabled when doing recovery on EEH errors so that the PE could function properly again. The patch implements it and abstract that through struct eeh_ops::set_eeh. It would be help for EEH to support multiple platforms in future. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Gavin Shan 提交于
The EEH has been implemented on pSeries platform. The original code looks a little bit nasty. The patch does cleanup on the current EEH implementation so that it looks more clean. * Try adding prefix "eeh" for functions. * Some function names have been adjusted so that they looks shorter and meaningful. Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 06 5月, 2011 1 次提交
-
-
由 Richard A Lary 提交于
For adapters which have devices under a PCIe switch/bridge it is informative to display information for both the PCIe switch/bridge and the device on which the bus error was detected. rebased to powerpc-next Signed-off-by: NRichard A Lary <rlary@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 17 2月, 2010 1 次提交
-
-
由 Breno Leitao 提交于
During a EEH recover, the pci_dev structure can be null, mainly if an eeh event is detected during cpi config operation. In this case, the pci_dev will not be known (and will be null) the kernel will crash with the following message: Unable to handle kernel paging request for data at address 0x000000a0 Faulting instruction address: 0xc00000000006b8b4 Oops: Kernel access of bad area, sig: 11 [#1] NIP [c00000000006b8b4] .eeh_event_handler+0x10c/0x1a0 LR [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0 Call Trace: [c0000003a80dff00] [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0 [c0000003a80dff90] [c000000000031f1c] .kernel_thread+0x54/0x70 The bug occurs because pci_name() tries to access a null pointer. This patch just guarantee that pci_name() is not called on Null pointers. Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com> Signed-off-by: NLinas Vepstas <linasvepstas@gmail.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 09 2月, 2010 1 次提交
-
-
由 Frans Pop 提交于
Signed-off-by: NFrans Pop <elendil@planet.nl> Cc: linuxppc-dev@ozlabs.org Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 30 10月, 2009 1 次提交
-
-
由 Michael Ellerman 提交于
Rather than open-coding our own check, use irq_has_action() to check if an irq has an action - ie. is "in use". irq_has_action() doesn't take the descriptor lock, but it shouldn't matter - we're just using it as an indicator that the irq is in use. disable_irq_nosync() will take the descriptor lock before doing anything also. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Acked-by: NGrant Likely <grant.likely@secretlab.ca> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 17 6月, 2009 1 次提交
-
-
由 Zhang, Yanmin 提交于
Based on PCI Express AER specs, a root port might receive multiple TLP errors while it could only save a correctable error source id and an uncorrectable error source id at the same time. In addition, some root port hardware might be unable to provide a correct source id, i.e., the source id, or the bus id part of the source id provided by root port might be equal to 0. The patchset implements the support in kernel by searching the device tree under the root port. Patch 1 changes parameter cb of function pci_walk_bus to return a value. When cb return non-zero, pci_walk_bus stops more searching on the device tree. Reviewed-by: NAndrew Patterson <andrew.patterson@hp.com> Signed-off-by: NZhang Yanmin <yanmin_zhang@linux.intel.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 15 4月, 2009 1 次提交
-
-
由 Mike Mason 提交于
While adding native EEH support to Emulex and Qlogic drivers, it was discovered that dev->error_state was set to pci_io_channel_normal too late in the recovery process. These drivers rely on error_state to determine if they can access the device in their slot_reset callback, thus error_state needs to be set to pci_io_channel_normal in eeh_report_reset(). Below is a detailed explanation (courtesy of Richard Lary) as to why this is necessary. Background: PCI MMIO or DMA accesses to a frozen slot generate additional EEH errors. If the number of additional EEH errors exceeds EEH_MAX_FAILS the adapter will be shutdown. To avoid triggering excessive EEH errors and an undesirable adapter shutdown, some drivers use the pci_channel_offline(dev) wrapper function to return a Boolean value based on the value of pci_dev->error_state to determine if PCI MMIO or DMA accesses are safe. If the wrapper returns TRUE, drivers must not make PCI MMIO or DMA access to their hardware. The pci_dev structure member error_state reflects one of three values, 1) pci_channel_io_normal, 2) pci_channel_io_frozen, 3) pci_channel_io_perm_failure. Function pci_channel_offline(dev) returns TRUE if error_state is pci_channel_io_frozen or pci_channel_io_perm_failure. The EEH driver sets pci_dev->error_state to pci_channel_io_frozen at the point where the PCI slot is frozen. Currently, the EEH driver restores dev->error_state to pci_channel_io_normal in eeh_report_resume() before calling the driver's resume callback. However, when the EEH driver calls the driver's slot_reset callback() from eeh_report_reset(), it incorrectly indicates the error state is still pci_channel_io_frozen. Waiting until eeh_report_resume() to restore dev->error_state to pci_channel_io_normal is too late for Emulex and QLogic FC drivers and any other drivers which are designed to use common code paths in these two cases: i) those called after the driver's slot_reset callback() and ii) those called after the PCI slot is frozen but before the driver's slot_reset callback is called. Case i) all driver paths executed to reinitialize the hardware after a reset and case ii) all code paths executed by driver kernel threads that run asynchronous to the main driver thread, such as interrupt handlers and worker threads to process driver work queues. Emulex and QLogic FC drivers are designed with common code paths which require that pci_channel_offline(dev) reflect the true state of the hardware. The state transitions that the hardware takes from Normal Operations to Slot Frozen to Reset to Normal Operations are documented in the Power Architecture™ Platform Requirements+ (PAPR+) in Table 75. PE State Control. PAPR defines the following 3 states: 0 -- Not reset, Not EEH stopped, MMIO load/store allowed, DMA allowed (Normal Operations) 1 -- Reset, Not EEH stopped, MMIO load/store disabled, DMA disabled 2 -- Not reset, EEH stopped, MMIO load/store disabled, DMA disabled (Slot Frozen) An EEH error places the slot in state 2 (Frozen) and the adapter driver is notified that an EEH error was detected. If the adapter driver returns PCI_ERS_RESULT_NEED_RESET, the EEH driver calls eeh_reset_device() to place the slot into state 1 (Reset) and eeh_reset_device completes by placing the slot into State 0 (Normal Operations). Upon return from eeh_reset_device(), the EEH driver calls eeh_report_reset, which then calls the adapter's slot_reset callback. At the time the adapter's slot_reset callback is called, the true state of the hardware is Normal Operations and should be accurately reflected by setting dev->error_state to pci_channel_io_normal. The current implementation of EEH driver does not do so and requires this change to correct this deficiency. Signed-off-by: NMike Mason <mmlnx@us.ibm.com> Acked-by: NLinas Vepstas <linasvepstas@gmail.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 11 2月, 2009 1 次提交
-
-
由 Mike Mason 提交于
The EEH code disables and enables interrupts during the device recovery process. This is unnecessary for MSI and MSI-X interrupts because they are effectively disabled by the DMA Stopped state when an EEH error occurs. The current code is also incorrect for MSI-X interrupts. It doesn't take into account that MSI-X interrupts are tracked in a different way than LSI/MSI interrupts. This patch ensures only LSI interrupts are disabled/enabled. Signed-off-by: NMike Mason <mmlnx@us.ibm.com> Acked-by: NLinas Vepstas <linasvepstas@gmail.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 20 8月, 2008 1 次提交
-
-
由 Tony Breeds 提交于
Currently print_device_node_tree() isn't called but it can be useful for debugging. Leave the function there but hide it behind '#if 0' to save it being rewritten. If you want to call it you're already editing this file anyway. ;P Signed-off-by: NTony Breeds <tony@bakeyournoodle.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 16 6月, 2008 1 次提交
-
-
由 Andrew Morton 提交于
Fix this: /usr/src/devel/arch/powerpc/platforms/pseries/eeh_driver.c: In function 'print_device_node_tree': /usr/src/devel/arch/powerpc/platforms/pseries/eeh_driver.c:55: warning: ISO C90 forbids mixed declarations and code also make that function look like it's part of Linux. Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 11 12月, 2007 1 次提交
-
-
由 Stephen Rothwell 提交于
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 03 12月, 2007 1 次提交
-
-
由 Linas Vepstas 提交于
Do not wait for the pci slot status before reporting an error to the device driver. Some systems may take many seconds to report the slot status, and this can confuse unsuspecting device drivers. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 08 11月, 2007 2 次提交
-
-
由 Linas Vepstas 提交于
Bugfix: if a driver controlling one part of a multi-function PCI card has asked for a reset, honor that request above all others. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Linas Vepstas 提交于
Clean up commentary, remove dead code. Signed-off-by Linas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 14 6月, 2007 1 次提交
-
-
由 Linas Vepstas 提交于
Twiddle the copyright notices. Per current guidelines, the use of the (C) or (c) in source code is deprecated. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> ---- arch/powerpc/platforms/pseries/eeh.c | 6 +++++- arch/powerpc/platforms/pseries/eeh_cache.c | 3 ++- arch/powerpc/platforms/pseries/eeh_driver.c | 6 +++--- 3 files changed, 10 insertions(+), 5 deletions(-) Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 10 5月, 2007 1 次提交
-
-
由 Linas Vepstas 提交于
Assorted minor cleanups to EEH code; -- use literals, use kerneldoc format. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> ---- arch/powerpc/platforms/pseries/eeh.c | 13 ++++++++++--- arch/powerpc/platforms/pseries/eeh_driver.c | 7 ++++--- include/asm-powerpc/ppc-pci.h | 18 +++++++++++++++--- 3 files changed, 29 insertions(+), 9 deletions(-) Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 09 5月, 2007 2 次提交
-
-
由 Linas Vepstas 提交于
Make some minor adjustments to the EEH error messages. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Linas Vepstas 提交于
It turns out many/most versions of firmware enable MMIO when the slto-error-detail rtas call is made (in violation of the architecture). Thus, it would be best to call slot-error-detail only after notifying device drivers of a freeze, as otherwise, a variety of strange and unexpected things may happen. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 13 4月, 2007 1 次提交
-
-
由 Stephen Rothwell 提交于
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 22 3月, 2007 6 次提交
-
-
由 Linas Vepstas 提交于
Rework how multi-function PCI devices are identified and traversed. This fixes a bug with multi-function recovery on Power4 that was introduced by a recent Power4 EEH patch. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Linas Vepstas 提交于
After requesting a state change, verify that the state change actually ocurred, and the system ends up in the expected state. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Linas Vepstas 提交于
The EEH event notification system passes around data that is not needed or at least, not used properly. Stop passing this data; get it in a more reliable fashion. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Linas Vepstas 提交于
If the second or higher function of a multi-function device fails to recover, this failure is not reported upwards. Fix this. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Linas Vepstas 提交于
If a device driver does not have native PCI error recovery, a hotplug error recovery will be attemped. In this case, the device driver will not report back whether its healthy or not; simply assume that it is. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Linas Vepstas 提交于
There are multiple code patchs tht resuls in a "permanent failure"; when examining rare events, it can be hard to see which was taken. This patch adds printk's to assist. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 24 1月, 2007 1 次提交
-
-
由 Linas Vepstas 提交于
Clarify error message re EEH permanent failure. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 08 12月, 2006 1 次提交
-
-
由 Linas Vepstas 提交于
If one attempts to create a device driver recovery sequence that does not depend on a hard reset of the device, but simply just attempts to resume processing, then one discovers that the recovery sequence implemented on powerpc is not quite right. This patch fixes this up. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 21 9月, 2006 2 次提交
-
-
由 Linas Vepstas 提交于
Update to the PowerPC PCI error recovery code. Add code to enable MMIO if a device driver reports that it is capable of recovering on its own. One anticipated use of this having a device driver enable MMIO so that it can take a register dump, which might then be followed by the device driver requesting a full reset. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Linas Vepstas 提交于
Clean up subroutine documentation; mostly formatting changes, with some new content. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 31 7月, 2006 1 次提交
-
-
由 Jeremy Kerr 提交于
Now that get_property() returns a void *, there's no need to cast its return value. Also, treat the return value as const, so we can constify get_property later. pseries platform changes. Built for pseries_defconfig Signed-off-by: NJeremy Kerr <jk@ozlabs.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 01 7月, 2006 1 次提交
-
-
由 Adrian Bunk 提交于
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 21 6月, 2006 1 次提交
-
-
由 Linas Vepstas 提交于
The PCI error recovery code will printk diagnostic info when a PCI error event occurs. Change the messages to include the slot location code, which is how most sysadmins will know the device. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 19 5月, 2006 1 次提交
-
-
由 Linas Vepstas 提交于
When a PCI device driver does not support PCI error recovery, the powerpc/pseries code takes a walk through a branch of code that resets the failure counter. Because of this, if a broken PCI card is present, the kernel will attempt to reset it an infinite number of times. (This is annoying but mostly harmless: each reset takes about 10-20 seconds, and uses almost no CPU time). This patch preserves the failure count across resets. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 22 4月, 2006 1 次提交
-
-
由 Linas Vepstas 提交于
The current PCI error recovery system keeps track of the number of PCI card resets, and refuses to bring a card back up if this number is too large. The goal of doing this was to avoid an infinite loop of resets if a card is obviously dead. However, if the failures are rare, but the machine has a high uptime, this mechanism might still be triggered; this is too harsh. This patch will avoids this problem by decrementing the fail count after an hour. Thus, as long as a pci card BSOD's less than 6 times an hour, it will continue to be reset indefinitely. If it's failure rate is greater than that, it will be taken off-line permanently. This patch is larger than it might otherwise be because it changes indentation by removing a pointless while-loop. The while loop is not needed, as the handler is invoked once fo each event (by schedule_work()); the loop is leftover cruft from an earlier implementation. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 01 4月, 2006 2 次提交
-
-
由 Linas Vepstas 提交于
The recent patch to print device names in EEH reset messages was lacking ... this patch works better. Signed-off-by: NLinas Vepstas <linas@linas.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
由 Linas Vepstas 提交于
The current code prints an ambiguous message if the recovery of a failed PCI device fails. Give this special case its own unique message. Signed-off-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 27 3月, 2006 1 次提交
-
-
由 Linas Vepstas 提交于
This avoids printk'ing a NULL string. Signed-off-by: NLinas Vepstas <linas@linas.org> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 28 2月, 2006 1 次提交
-
-
由 Olaf Hering 提交于
This patch fixes a crash in handle_eeh_events, but ethtool -t still doesnt work right. ... pepino:~ # cpu 0x3: Vector: 300 (Data Access) at [c00000005192bbe0] pc: c00000000004a380: .handle_eeh_events+0xe0/0x23c lr: c00000000004a374: .handle_eeh_events+0xd4/0x23c sp: c00000005192be60 msr: 9000000000009032 dar: 268 dsisr: 40000000 current = 0xc0000001fe7bf1a0 paca = 0xc00000000048b280 pid = 16322, comm = eehd enter ? for help [c00000005192bf00] c00000000004a808 .eeh_event_handler+0xcc/0x130 [c00000005192bf90] c000000000025e00 .kernel_thread+0x4c/0x68 ... (none):/# /usr/sbin/ethtool -i eth0 driver: e100 version: 3.5.10-k2-NAPI firmware-version: N/A bus-info: 0000:21:01.0 (none):/# /usr/sbin/ethtool -t eth0 Call Trace: [C00000000F8DEFF0] [C00000000000F270] .show_stack+0x74/0x1b4 (unreliable) [C00000000F8DF0A0] [C000000000049D04] .eeh_dn_check_failure+0x290/0x2d8 [C00000000F8DF150] [C000000000049E58] .eeh_check_failure+0x10c/0x138 [C00000000F8DF1E0] [C0000000002DFDB0] .e100_hw_reset+0x70/0xf4 [C00000000F8DF270] [C0000000002E1BBC] .e100_hw_init+0x2c/0x260 [C00000000F8DF310] [C0000000002E2464] .e100_loopback_test+0x8c/0x220 [C00000000F8DF3C0] [C0000000002E28DC] .e100_diag_test+0xdc/0x16c [C00000000F8DF490] [C000000000420BE0] .dev_ethtool+0xf24/0x14f8 [C00000000F8DF8F0] [C00000000041F4A8] .dev_ioctl+0x5cc/0x740 [C00000000F8DFA20] [C00000000040FEFC] .sock_ioctl+0x3d0/0x404 [C00000000F8DFAC0] [C0000000000D513C] .do_ioctl+0x68/0x108 [C00000000F8DFB50] [C0000000000D56B0] .vfs_ioctl+0x4d4/0x510 [C00000000F8DFC10] [C0000000000D5740] .sys_ioctl+0x54/0x94 [C00000000F8DFCC0] [C0000000000FB6EC] .ethtool_ioctl+0x11c/0x150 [C00000000F8DFD60] [C0000000000F7E40] .compat_sys_ioctl+0x338/0x3bc [C00000000F8DFE30] [C00000000000871C] syscall_exit+0x0/0x40 EEH: Detected PCI bus error on device 0000:21:01.0 EEH: This PCI device has failed 1 times since last reboot: <NULL> - modprobe: FATAL: Could not load /lib/modules/2.6.16-rc4-git7/modules.dep: No such file or directory Cannot get strings: No such device (none):/# (none):/# EEH: Unable to configure device bridge (-3) for /pci@400000000110/pci@2,2 (none):/# Call Trace: [C00000000FA17940] [C00000000000F270] .show_stack+0x74/0x1b4 (unreliable) [C00000000FA179F0] [C000000000049D04] .eeh_dn_check_failure+0x290/0x2d8 [C00000000FA17AA0] [C00000000001E114] .rtas_read_config+0x120/0x154 [C00000000FA17B40] [C000000000049664] .early_enable_eeh+0x274/0x2bc [C00000000FA17C00] [C000000000049708] .eeh_add_device_early+0x5c/0x6c [C00000000FA17C90] [C000000000049748] .eeh_add_device_tree_early+0x30/0x5c [C00000000FA17D20] [C000000000046568] .pcibios_add_pci_devices+0x8c/0x1f8 [C00000000FA17DD0] [C00000000004A528] .eeh_reset_device+0xe0/0x110 [C00000000FA17E60] [C00000000004A698] .handle_eeh_events+0x140/0x250 [C00000000FA17F00] [C00000000004AC7C] .eeh_event_handler+0xe8/0x140 [C00000000FA17F90] [C000000000025784] .kernel_thread+0x4c/0x68 EEH: Detected PCI bus error on device <NULL> EEH: This PCI device has failed 1 times since last reboot: <NULL> - EEH: Unable to configure device bridge (-3) for /pci@400000000110/pci@2,2 Call Trace: [C00000000FA17940] [C00000000000F270] .show_stack+0x74/0x1b4 (unreliable) [C00000000FA179F0] [C000000000049D04] .eeh_dn_check_failure+0x290/0x2d8 [C00000000FA17AA0] [C00000000001E114] .rtas_read_config+0x120/0x154 [C00000000FA17B40] [C000000000049664] .early_enable_eeh+0x274/0x2bc [C00000000FA17C00] [C000000000049708] .eeh_add_device_early+0x5c/0x6c [C00000000FA17C90] [C000000000049748] .eeh_add_device_tree_early+0x30/0x5c [C00000000FA17D20] [C000000000046568] .pcibios_add_pci_devices+0x8c/0x1f8 [C00000000FA17DD0] [C00000000004A528] .eeh_reset_device+0xe0/0x110 [C00000000FA17E60] [C00000000004A698] .handle_eeh_events+0x140/0x250 [C00000000FA17F00] [C00000000004AC7C] .eeh_event_handler+0xe8/0x140 [C00000000FA17F90] [C000000000025784] .kernel_thread+0x4c/0x68 EEH: Detected PCI bus error on device <NULL> EEH: This PCI device has failed 1 times since last reboot: <NULL> - EEH: Unable to configure device bridge (-3) for /pci@400000000110/pci@2,2 Call Trace: [C00000000FA17940] [C00000000000F270] .show_stack+0x74/0x1b4 (unreliable) [C00000000FA179F0] [C000000000049D04] .eeh_dn_check_failure+0x290/0x2d8 [C00000000FA17AA0] [C00000000001E114] .rtas_read_config+0x120/0x154 [C00000000FA17B40] [C000000000049664] .early_enable_eeh+0x274/0x2bc [C00000000FA17C00] [C000000000049708] .eeh_add_device_early+0x5c/0x6c [C00000000FA17C90] [C000000000049748] .eeh_add_device_tree_early+0x30/0x5c [C00000000FA17D20] [C000000000046568] .pcibios_add_pci_devices+0x8c/0x1f8 [C00000000FA17DD0] [C00000000004A528] .eeh_reset_device+0xe0/0x110 [C00000000FA17E60] [C00000000004A698] .handle_eeh_events+0x140/0x250 [C00000000FA17F00] [C00000000004AC7C] .eeh_event_handler+0xe8/0x140 [C00000000FA17F90] [C000000000025784] .kernel_thread+0x4c/0x68 EEH: Detected PCI bus error on device <NULL> and so on Signed-off-by: NOlaf Hering <olh@suse.de> Acked-by: NLinas Vepstas <linas@austin.ibm.com> Signed-off-by: NPaul Mackerras <paulus@samba.org>
-
- 08 2月, 2006 1 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-