Page MenuHomeFreeBSD

if_bnxt: fix HWRM failures/timeouts after repeated FW resets
AcceptedPublic

Authored by sumit.saxena_broadcom.com on Mon, Aug 3, 1:07 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Aug 27, 11:43 PM
Unknown Object (File)
Sun, Aug 23, 8:12 PM
Unknown Object (File)
Sun, Aug 23, 1:52 PM
Unknown Object (File)
Sat, Aug 22, 2:08 AM
Unknown Object (File)
Fri, Aug 21, 9:24 PM
Unknown Object (File)
Wed, Aug 19, 8:36 AM
Unknown Object (File)
Tue, Aug 18, 9:11 AM
Unknown Object (File)
Sat, Aug 15, 9:32 PM
Subscribers
None

Details

Summary

Consecutive firmware-initiated reset cycles produced HWRM
failures/timeouts and traffic didn't come back. Fix the FW-reset
recovery path:

  • bnxt_fw_reset_close() called bnxt_stop() and bnxt_hwrm_func_drv_unrgtr(), sending HWRM ring/VNIC/filter free commands to a firmware that's already mid-reset and unresponsive, producing the observed timeouts. Both are unnecessary since firmware comes back with fresh state anyway; drop them along with the now-redundant iflib_request_reset().
  • bnxt_func_reset() now skips bnxt_hwrm_resource_free() entirely while BNXT_STATE_IN_FW_RESET is set, for the same reason.
  • bnxt_open() (used to reopen after a firmware reset) now issues bnxt_hwrm_func_reset() up front and drives reinit through iflib's own reset machinery (iflib_request_reset() plus a new bnxt_iflib_reset_sync() that waits for IFF_DRV_RUNNING/OACTIVE to flip 1->0->1) instead of calling bnxt_init()/bnxt_intr_enable() directly.
  • Route repeated PORT_QSTATS/PORT_QSTATS_EXT HWRM timeouts through bnxt_log_live() instead of device_printf(), so a stats poll timing out during a reset doesn't spam dmesg on every tick.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped