search for: slot_reset

...g MMIO/config Suggestion 1: ignore this. vm stop happens much later when userspace runs anyway, so we are not making things much worse Suggestion 2: detect this and invoke err_trigger to stop VM Patch below implements Suggestion 2. Aside: what should we return if driver is e.g. being unbound? For slot_reset, this implements Alex's suggestion to return PCI_ERS_RESULT_NONE. It's worth considering whether same should happen in error_report. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- changes from v1: - more detailed commit log - fixed a couple of bugs Alex, pls review but...

...g MMIO/config Suggestion 1: ignore this. vm stop happens much later when userspace runs anyway, so we are not making things much worse Suggestion 2: detect this and invoke err_trigger to stop VM Patch below implements Suggestion 2. Aside: what should we return if driver is e.g. being unbound? For slot_reset, this implements Alex's suggestion to return PCI_ERS_RESULT_NONE. It's worth considering whether same should happen in error_report. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- changes from v1: - more detailed commit log - fixed a couple of bugs Alex, pls review but...

...t 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 above four processing. Pcibac...

...s 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 replace the dual-port 1G card with a quad-port 1...

...g MMIO/config Suggestion 1: ignore this. vm stop happens much later when userspace runs anyway, so we are not making things much worse Suggestion 2: detect this and invoke err_trigger to stop VM Patch below implements Suggestion 2. Aside: what should we return if driver is e.g. being unbound? For slot_reset, this implements Alex's suggestion to return PCI_ERS_RESULT_NONE. It's worth considering whether same should happen in error_report. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Completely untested by myself. Will be build-tested by 0-day :) changes from v2: - fix bui...

...g MMIO/config Suggestion 1: ignore this. vm stop happens much later when userspace runs anyway, so we are not making things much worse Suggestion 2: detect this and invoke err_trigger to stop VM Patch below implements Suggestion 2. Aside: what should we return if driver is e.g. being unbound? For slot_reset, this implements Alex's suggestion to return PCI_ERS_RESULT_NONE. It's worth considering whether same should happen in error_report. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Completely untested by myself. Will be build-tested by 0-day :) changes from v2: - fix bui...

...cted (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. Could it be a common problem with either the adapters, or...

...or_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 0 devfn 1 [ 2985.145777] pcieport 0000:00:07.0: broadcast slot_reset message [ 2985.145783] pciback 0000:04:00.0: pciback_slot_reset(bus:4,devfn:0) [ 2985.145790] pciback 0000:04:00.0: pciback: aer_op 9 dom 0 bus 0 devfn 0 [ 2985.552672] pciback 0000:04:00.0: set power state to 0 [ 2985.622153] pciback 0000:04:00.1: pciback_slot_reset(bus:4,devfn:1) [ 2985.622161] p...

...pe=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. Could it be a common > problem wi...

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