Re: [PATCH rtw-next] wifi: rtw88: usb: send broadcast/multicast via the AC queues

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

On 13/08/2026 18:52, Mehmet Fide wrote:
> From: Mehmet Fide <mehmet.fide@screeningeagle.com>
> 
> Hello Bitterblue,
> 
>> I wonder if you can reproduce this problem with kernel 6.5? It looks
>> like commit 076f786a0ae1 ("wifi: rtw88: Fix AP mode incorrect DTIM
>> behavior") from 6.5 was supposed to fix the exact same problem.
>> This is also the commit which introduced the code you are now removing.
> 
> Thanks, I was not aware of that commit, and you are right that my patch
> reverts exactly the usb.c hunk of it; the MORE_DATA and HGQMD parts
> stay. I will say that in the commit message in a v2.
> 
> I did not run 6.5 and cannot easily on this hardware, the board support
> we run starts at 6.12. I do not think it would add information though:
> the code from 076f786a0ae1 is unchanged between 6.5 and the 6.12.103 I
> tested, and it was demonstrably engaged while the AP was wedged. In a
> register snapshot taken in that state REG_TCR reads 0x00303030, so
> BIT_TCR_UPDATE_HGQMD was set. Still, the high queue drained at about 14
> frames a second, roughly 3 frames per DTIM at beacon interval 100 and
> dtim_period 2, measured over minutes from the URB submit/complete
> counters, while several hundred frames sat queued. So at least on
> RTL8822BU the burst fetch does not happen even with that fix active.
> RTL8821CU behaves the same, measured today on the same bench with only
> the dongle swapped: stock fails the reconnect test 0/3 with the "error
> beacon valid" messages appearing, and passes 5/5 with none once the bmc
> routing is reverted. RTL8822BU is 0/5 stock and 10/10 with the revert.
> 
> I also think the two problems are different. 076f786a0ae1 addresses the
> hardware fetching one buffered packet per DTIM instead of the whole
> burst. What we hit is sustained inflow above any DTIM-paced outflow: on
> USB the high queue shares the single bulk-out endpoint and the page
> pool with the beacon and H2C queues, so once the pool is exhausted
> (measured: 14 of 1803 pages left) the beacon reserved-page download
> fails ("error beacon valid"), the TIM stops updating, and the firmware
> never releases the burst, which closes the loop and no station can
> associate again.
> 
> If you would rather keep the after-DTIM delivery for stations in power
> save, I am happy to test an alternative, for example routing bmc to the
> high queue only while a station is actually in PS, or a depth cap on
> the high queue. On this hardware the plain AC-queue routing is what I
> could verify.
> 
> Thanks,
> Mehmet

Could you check what the official driver is doing in the same situation?

https://github.com/morrownr/88x2bu-20210702