diff options
| author | 2016-06-07 16:08:51 -0700 | |
|---|---|---|
| committer | 2016-07-20 15:22:12 -0700 | |
| commit | 94877768cfaa99f7b3757f29632faa5945f18872 (patch) | |
| tree | 37e9aa4651febb2ff39f9a5b2487d195edfc459a /scripts/gdb/linux/dmesg.py | |
| parent | fm10k: only warn when stop_hw fails with FM10K_ERR_REQUESTS_PENDING (diff) | |
| download | wireguard-linux-94877768cfaa99f7b3757f29632faa5945f18872.tar.xz wireguard-linux-94877768cfaa99f7b3757f29632faa5945f18872.zip | |
fm10k: wait for queues to drain if stop_hw() fails once
It turns out that sometimes during a reset the Tx queues will be
temporarily stuck longer than .stop_hw() expects. Work around this issue
by attempting to .stop_hw() first. If it tails, wait a number of
attempts until the Tx queues appear to be drained. After this, attempt
stop_hw() again. This ensures that we avoid waiting if we don't need to,
such as during the first initialization of a VF, and give the proper
amount of time necessary to recover from most situations. It is possible
that the hardware is actually stuck. For PFs, this is usually fixed by
a datapath reset. Unfortunately the VF cannot request a similar reset
for itself.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Diffstat (limited to 'scripts/gdb/linux/dmesg.py')
0 files changed, 0 insertions, 0 deletions
