search for: error_detect

...ll be FLRed). For HVM guest, it will be killed obviously. 4) Trigger AER by test driver, an interrupt will be generated and caught by root port. 5) AER service driver below root port in DOM0 will help to do the recovery steps in bottom half of the aer interrupt context. For each recovery process (error_detected, mmio_enabled, slot_reset, error_resume), aer core will cooperate with each below devices which has registered pci_error_handlers to finish the process. For details, please see the related docs in kernel (attached aer_doc.patch). 6) pciback_error_handler will then be called by AER core for each a...

...) error received: id=0000 igb 0000:04:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=0401(Requester ID) igb 0000:04:00.1: device [8086:10a7] error status/mask=00004000/00000000 igb 0000:04:00.1: [14] Completion Timeout (First) igb 0000:04:00.1: broadcast error_detected message igb 0000:04:00.1: broadcast slot_reset message igb 0000:04:00.1: broadcast resume message igb 0000:04:00.1: AER: Device recovery successful Spammed continuously. Switching to Broadcom would be a possibility, though it's tricky because two of the NICs are onboard, so we'd need to...

...ion 1: ignore this. vm stop happens much later when userspace runs anyway, so we are not making things much worse Suggestion 2: try to stop MMIO/config, resume on resume call Patch below implements Suggestion 1. Note that although this is really against the documentation, which states error_detected() is the point at which the driver should quiesce the device and not touch it further (until diagnostic poking at mmio_enabled or full access at resume callback). Fixing this won't be easy. However, this is not a regression. Also note this does nothing about interrupts, documentation suggest...

...ion 1: ignore this. vm stop happens much later when userspace runs anyway, so we are not making things much worse Suggestion 2: try to stop MMIO/config, resume on resume call Patch below implements Suggestion 1. Note that although this is really against the documentation, which states error_detected() is the point at which the driver should quiesce the device and not touch it further (until diagnostic poking at mmio_enabled or full access at resume callback). Fixing this won't be easy. However, this is not a regression. Also note this does nothing about interrupts, documentation suggest...

...ion 1: ignore this. vm stop happens much later when userspace runs anyway, so we are not making things much worse Suggestion 2: try to stop MMIO/config, resume on resume call Patch below implements Suggestion 1. Note that although this is really against the documentation, which states error_detected() is the point at which the driver should quiesce the device and not touch it further (until diagnostic poking at mmio_enabled or full access at resume callback). Fixing this won't be easy. However, this is not a regression. Also note this does nothing about interrupts, documentation suggest...

...ion 1: ignore this. vm stop happens much later when userspace runs anyway, so we are not making things much worse Suggestion 2: try to stop MMIO/config, resume on resume call Patch below implements Suggestion 1. Note that although this is really against the documentation, which states error_detected() is the point at which the driver should quiesce the device and not touch it further (until diagnostic poking at mmio_enabled or full access at resume callback). Fixing this won't be easy. However, this is not a regression. Also note this does nothing about interrupts, documentation suggest...

...> igb 0000:04:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fatal), > type=Transaction Layer, id=0401(Requester ID) > igb 0000:04:00.1: device [8086:10a7] error status/mask=00004000/00000000 > igb 0000:04:00.1: [14] Completion Timeout (First) > igb 0000:04:00.1: broadcast error_detected message > igb 0000:04:00.1: broadcast slot_reset message > igb 0000:04:00.1: broadcast resume message > igb 0000:04:00.1: AER: Device recovery successful This is interesting. We've never had any problems with the 1Gb NICs, but we're only using 10Gb for the storage network. Coul...

...74855] pcieport 0000:00:07.0: device [8086:340e] error status/mask=00100000/00218000 [ 2985.074862] pcieport 0000:00:07.0: [20] Unsupported Request (First) [ 2985.074869] pcieport 0000:00:07.0: TLP Header: 6000201d 0400003f 21f91a41 aecadb80 [ 2985.074886] pcieport 0000:00:07.0: broadcast error_detected message [ 2985.074893] pciback 0000:04:00.0: pciback_error_detected(bus:4,devfn:0) [ 2985.074902] pciback 0000:04:00.0: pciback: aer_op 6 dom 0 bus 0 devfn 0 [ 2985.145525] pciback 0000:04:00.1: pciback_error_detected(bus:4,devfn:1) [ 2985.145533] pciback 0000:04:00.1: pciback: aer_op 6 dom 0 bus...

...ort > 0000:00:05.0: device [8086:340c] error > status/mask=00004000/00000000 > Mar 10 02:57:05 SunBlade2 kernel: [ 1496.023742] pcieport > 0000:00:05.0: [14] Completion Timeout (First) > Mar 10 02:57:05 SunBlade2 kernel: [ 1496.024193] pcieport > 0000:00:05.0: broadcast error_detected message > Mar 10 02:57:05 SunBlade2 kernel: [ 1496.024198] pciback 0000:0e:00.0: > pciback device is not found/assigned > Mar 10 02:57:05 SunBlade2 kernel: [ 1496.024201] pcieport > 0000:00:05.0: broadcast mmio_enabled message > Mar 10 02:57:05 SunBlade2 kernel: [ 1496.024203] p...

...CIe Bus Error: severity=Uncorrected (Non-Fatal), >> type=Transaction Layer, id=0401(Requester ID) >> igb 0000:04:00.1: device [8086:10a7] error >> status/mask=00004000/00000000 >> igb 0000:04:00.1: [14] Completion Timeout (First) >> igb 0000:04:00.1: broadcast error_detected message >> igb 0000:04:00.1: broadcast slot_reset message >> igb 0000:04:00.1: broadcast resume message >> igb 0000:04:00.1: AER: Device recovery successful > > This is interesting. We've never had any problems with the 1Gb NICs, but > we're only using 10Gb for...

On 01/27/2017 06:08 AM, Karel Hendrych wrote: > Have you tried to eliminate all power management features all over? I've been trying to find and disable all power management features but having relatively little luck with that solving the problems. Stabbing the the dark I've tried different ACPI settings, including completely disabling it, disabling CPU frequency scaling, and setting

Hello, I''m hoping someone may be able to push us in the right direction. I''m trying to get one of our products to work with the current branch of Xen (4.0/4.0.0) but I''m hitting a problem. We are currently using Xen 3.3.2 on a Sun Blade 600 chassis (with x6270 blades) this works great. But when we upgrade to Xen 4.0/4.0.1 we get the following message when

Hi everyone, Having proper error handling in LLVM's Object parsing library is a nice thing by itself, but it would additionally allow us to find bugs by fuzzing (see r238451 that adds llvm-dwarfdump-fuzzer tool), for which the clean input validation is essential. This is a generic discussion of state of affairs. I want to do some progress in fuzzing before we finish it (especially if we