Greetings:

I am sending this series as an extension to my v4 [1] which was just 1 patch.

Note that patch 5 of this series can now cause the device to fail closed if
memory is tight; bnxt_init_nic propagates an error that was previously
swallowed and fails closed instead of succeeding in a degraded state. If the
maintainers want the device to come up with a partially populated rx_tpa[],
then patch 5 can be dropped and this series can still be applied
and will otherwise work as intended.

This series addresses a variety of bugs orbiting the TPA code in the bnxt
driver that Sashiko (or Clashiko or whatever) pointed out and the series ends
with the patch from the v4 [1].

A lot of the noise generated by the AIs while reviewing my v4 are unrelated
bugs with different fixes tags that, IMHO, distract a bit from the crash at
boot that is currently occurring with Thor2 hardware on recent kernels.

That said, I've tried to wrangle this series together which I hope will solve
most of the important bugs the AIs are feeling something about.

I do not know what other rabbit holes the AIs will find when I submit this
series, but if there is some reasonable stop-gap that we can get applied to
fix the crashes on Thor2 (while I iterate on the rest of the bugs at the
pleasure of the AIs) that would be excellent.

I boot tested this on a Thor1 and a Thor2 machine and there were no crashes at
boot.

Thanks,
Joe

[1]: https://lore.kernel.org/all/20260828190900.1767611-1-joe@dama.to/

Joe Damato (6):
  bnxt_en: Only restore LRO if the device supports TPA
  bnxt_en: Don't free the live ring's TPA state on queue restart failure
  bnxt_en: Propagate TPA buffer allocation failures in
    bnxt_queue_mem_alloc()
  bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset()
  bnxt_en: Propagate RX ring init failures in bnxt_init_nic()
  bnxt_en: Bound SW TPA IDs to prevent crashes

 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 57 +++++++++++++++++------
 drivers/net/ethernet/broadcom/bnxt/bnxt.h |  2 +-
 2 files changed, 43 insertions(+), 16 deletions(-)


base-commit: 1d2929d0850fff683b8aff051275945e65f082c8
-- 
2.53.0-Meta

On 9/2/26 3:56 AM, Joe Damato wrote:
> I am sending this series as an extension to my v4 [1] which was just 1 patch.
> 
> Note that patch 5 of this series can now cause the device to fail closed if
> memory is tight; bnxt_init_nic propagates an error that was previously
> swallowed and fails closed instead of succeeding in a degraded state. If the
> maintainers want the device to come up with a partially populated rx_tpa[],
> then patch 5 can be dropped and this series can still be applied
> and will otherwise work as intended.
> 
> This series addresses a variety of bugs orbiting the TPA code in the bnxt
> driver that Sashiko (or Clashiko or whatever) pointed out and the series ends
> with the patch from the v4 [1].
> 
> A lot of the noise generated by the AIs while reviewing my v4 are unrelated
> bugs with different fixes tags that, IMHO, distract a bit from the crash at
> boot that is currently occurring with Thor2 hardware on recent kernels.
> 
> That said, I've tried to wrangle this series together which I hope will solve
> most of the important bugs the AIs are feeling something about.
> 
> I do not know what other rabbit holes the AIs will find when I submit this
> series, but if there is some reasonable stop-gap that we can get applied to
> fix the crashes on Thor2 (while I iterate on the rest of the bugs at the
> pleasure of the AIs) that would be excellent.
> 
> I boot tested this on a Thor1 and a Thor2 machine and there were no crashes at
> boot.
Waiting for Michael's ack here. Note that I think that the AI report on
patch 5 is not a blocker.

/P

On Thu, Sep 03, 2026 at 11:37:34AM +0200, Paolo Abeni wrote:
> On 9/2/26 3:56 AM, Joe Damato wrote:

[...]

> > I boot tested this on a Thor1 and a Thor2 machine and there were no crashes at
> > boot.
> Waiting for Michael's ack here. Note that I think that the AI report on
> patch 5 is not a blocker.

Aright. If there's no reply within 24hr of posting do you want me to spin a v6
that:
  - fixes the commit message sashiko doesnt like for patch 4
  - fixes the resets stat it mentions in patch 4
  - add the return value check for bnxt_init_ring_grps in patch 5

or just leave the series as is ?

On 9/3/26 5:19 PM, Joe Damato wrote:
> On Thu, Sep 03, 2026 at 11:37:34AM +0200, Paolo Abeni wrote:
>> On 9/2/26 3:56 AM, Joe Damato wrote:
> 
> [...]
> 
>>> I boot tested this on a Thor1 and a Thor2 machine and there were no crashes at
>>> boot.
>> Waiting for Michael's ack here. Note that I think that the AI report on
>> patch 5 is not a blocker.
> 
> Aright. If there's no reply within 24hr of posting do you want me to spin a v6
> that:
>   - fixes the commit message sashiko doesnt like for patch 4
>   - fixes the resets stat it mentions in patch 4
>   - add the return value check for bnxt_init_ring_grps in patch 5
> 
> or just leave the series as is ?
No other revision required IMHO just for the above. The 2nd and 3rd
points could be eventually follow-ups.

/P