[RFC net v4 0/4] bnxt_en: Make RING FREE more robust

From: Joe Damato

Date: Fri Sep 25 2026 - 13:44:17 EST


Greetings:

This is a follow up to the previous RFC (linked below), updated based on
feedback from Michael.

On two production systems, I saw the following dmesg pattern:

NETDEV WATCHDOG: transmit queue 0 timed out 6073 ms
Resp cmpl intr err msg: 0x51 x20
hwrm_ring_free type 1 failed x12
hwrm_ring_free type 2 failed x8
AMD-Vi: IO_PAGE_FAULT x3

This suggests that, for some currently unknown reason, TX completions stall
and the netdev watchdog fires. The driver asks FW to free the rings, this
times out, but the driver ignores the possible failure and frees ring memory.
Since the FW didn't respond to the ring free command, it is possible that the
FW is still DMAing to the memory which was freed.

This series tries to prevent this by:

- Returning and checking ring free command return values
- Examining the FW response if the ring free command times out. It is
possible that, for some reason, the FW did complete the ring free but was
unable to respond with an IRQ. This seems unlikely given what appears to be
a use after free in dmesg, but worth logging just in case.
- Stop DMA before the driver frees ring memory, which should prevent
any possible use after free.
- Set a bit in the state flags to signal that DMA was stopped. This prevents
the device from being reopened without user intervention.

In the future, this could possibly be extended to make recovery automatic.

Sending this as an RFC so that the Broadcom folks have some time to take a
look and test as needed.

Thanks,
Joe

v4:
- No changes to patch 1 or 2
- Patch 3: reworded the message logged when DMA is stopped, a rebind is
what recovers the device, not a firmware reset. No functional change.
- Patch 4 added which adds a new bit (BNXT_STATE_DMA_STOPPED) that is set
when DMA is disabled. When this bit is set, the device requires user
intervention to bring back up.

v3: https://lore.kernel.org/netdev/20260923210744.3406861-1-joe@xxxxxxx/
- No changes to patch 1
- Patch 2: Don't poll for the valid bit as Michael suggested.
- Patch 3: bnxt_hwrm_ring_free now returns -EIO instead of stopping the
device, so the remaining resources can be freed and the remaining commands
can be sent before stopping the device, as Michael suggested. Note the
switch to using pci_clear_master in this patch instead of
pci_disable_device. This was done so that the normal shutdown paths can
call pci_disable_device without generating a warning.

v2: https://lore.kernel.org/netdev/20260922182405.1290749-1-joe@xxxxxxx/
- No changes to patch 1
- Patch 2 from v1 dropped
- Patch 2 in the v2 now checks the response and logs state before giving up
- Patch 3 in the v2 disables the device to stop DMA before freeing ring
memory

RFCv1: https://lore.kernel.org/netdev/20260917233218.1160001-1-joe@xxxxxxx/

Joe Damato (4):
bnxt_en: return the RING_FREE status to callers
bnxt_en: check HWRM response if completion never arrives
bnxt_en: stop DMA before releasing rings the firmware did not free
bnxt_en: refuse to open a device with stopped DMA

drivers/net/ethernet/broadcom/bnxt/bnxt.c | 122 ++++++++++++------
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 1 +
.../net/ethernet/broadcom/bnxt/bnxt_hwrm.c | 33 ++++-
3 files changed, 115 insertions(+), 41 deletions(-)


base-commit: 11536ee3d3e0b1bd35b6f3f8df55a6053eb0c71d
--
2.53.0-Meta