Re: [PATCH rtw-next] wifi: rtw88: pci: recover from a stalled TX ring

[abkarada <abdurrahmankaradag19@gmail.com>]

Sorry for the slow reply. I wanted to answer your questions with
measurements rather than with an opinion, and that took a while.

> > +               stopped = ring->queue_stopped;
> > +               ring->last_rp = cur_rp;
>
> Does software pointer cause driver doesn't restart queue?
> Or without changes of this chunk, the stuck can be resolved?

No. last_rp and stall_cnt are detection state only; they never touch the
data path. The only action in the patch is the kick below.

> I mean just doing this kick is enough to resolve the stuck?

No, and you were right to ask twice.

I taught my watchdog to rewrite the TXBD host index during a real stall
and then measure whether the hardware read index moves. Three live
occurrences since:

  2026-09-06 03:17   BE rp 0x00b7 before and after the rewrite
  2026-09-14 17:48   BE rp 0x00c9 before and after (wp 0x6c -> 0x6d)
  2026-09-14 19:09   BE rp 0x009e before and after (wp 0x50 -> 0x51)

In all three the read index never moved and traffic stayed at 100% loss.
The premise of this patch is wrong: the hardware is not waiting to be
told about new descriptors, it has stopped consuming them, and writing
the doorbell again changes nothing.

Please drop this patch. I will not resend it in this form.

I have sent a longer reply in the bug thread with the rest of the data,
including the fact that the stall also happens on 7.0.12, so my earlier
good/bad version claim was wrong as well. It also proposes a different
direction for the driver side, which I would rather agree with you
before writing.

Thanks for the review, and for pushing back on the mechanism.