From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC4B82F7F17 for ; Fri, 14 Aug 2026 05:34:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786685672; cv=none; b=Mcbnoh9oUeHKDQseamUYChFCQjayKDGc0EEc3frHjGytVfYlJSx619Se8pWiMgjWWxtOaQXaUwCtwm6GCJNOW2KnXVIc2MJ2jPc0Ean1K7AHpdrQW5d4A+ShTS83Tz9OfVMhWPc0y8emS/Ix4pdKh5BYsjWk0IllG+Vwe4ynKis= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786685672; c=relaxed/simple; bh=suc85FrtLbQf22brsB88D7OYPOdq4ICoJ0e4DPW6Pm4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=hKoXnqu8DJoJHYMArrviKnHzQ0+lnb6EsQrjnq0fYmamnNgDIlu2X4JCcjf4pjVgg1OgUoJiScDQV+da9+MXzhge7qPSjjlsA8e0B9aLnK+nPt2JItih4T+T4/v9fdUJ0cptHivG63SVsy8f/pHEWDVhe+xyWyl8au3rtSyoq2w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=T5eFXajf; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="T5eFXajf" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49557167508so5453555e9.1 for ; Thu, 13 Aug 2026 22:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786685668; x=1787290468; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=NweZTATsw473HUSw2qvH+SmBzWknsDyQl1KkkpxMyrQ=; b=T5eFXajfTv9dmPFT1mIOUSK2x67gjqVmEe5rC5rz82FbaWEBVX9uJ94cyzidXjvSYK WhFlmsQt3XjS57YYFJt2Bav7sjtua4LCAKQKxiezfhtbJRht8cZQpFUVfkmlMsSIfGmG CFSfZCh1bU347J8AqyCcCD93Syh5GYQ4CDmH/CiOKyxVcl+TE653nB1sztnygWwAafm+ V0hxtgKE3Nvm8ZFYtbKjGZW70atmZtuznVEfOe+iwH1WBIIWARch8YzqaBCcsamfR6sn nV0gphbiI/pPhh0EP3Rd42GGoUxaxdTlSIXbFXP7Azv7ZpJjANhgUFT+Ky6uQPZVwOIK xVjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786685668; x=1787290468; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=NweZTATsw473HUSw2qvH+SmBzWknsDyQl1KkkpxMyrQ=; b=a/BZh78Gtvwkb2yOU9brNc1ZBzslsy8PkUvNTvTYEPWtHeknrkLmrxnbtOkVmWSdfM 2KuEmvd7n5VT1JlltmspMbuVTli75aWpTzq7taq02yobcgwNAt/8GMlBRIo/wssJS8rw RK7Tu9Tnu5yDFz8zCBiLIDX/rhpS5vUQVmKS8QrGb8qbyy9MLnh7xsdWyUVZRWnnOPc3 y3+L9tFp+VDdHHEDTkinSZUUb3CmSUpOQvpWpRZPY5Ieor7XTqggOE/Vd5/gAnb2W3F3 oXNl6tLQpnKiDsWdc6TJyI9CsNAzZZ02YlsDw7Du3cAO1H7DH0VKVKwpkndq3ff0lR7z wasQ== X-Forwarded-Encrypted: i=1; AHgh+RrFUG1UQSHGqNGzhvnZH/15kW1496Ka5mFaZv9UmH6OPU7x36P0xv96rWY+eJ2a+m2EEM8GlZwGWqBPuM0=@vger.kernel.org X-Gm-Message-State: AOJu0YwEkGsfiCeoIxRSme+bqgwWJkv/+uH0HDR4RafZxn3z7onNu5P3 qO4BMpTmsKNQ/wW27JnDp210HvbyvkstYffxjV7izxAwZgznN1r+2IeS X-Gm-Gg: AR+sD13YocGCpV8wK810YKkRChOfqLE7I0J/0I3vA06w+NSZ9a5LsZttBos0LkKYiqe IxAQnPtX++f/R59Zs4k7M/9tiXbR343DQQ3XDnMCo6RVOK+Ap5Wi9de8Iy/DS4i70E1oxfglyoS 5yu4/WzFuzpra0SOcNiOKX1i1K5jSTqt5/8QFpUt5+XrRy5hCySZh5UMJTD7re7t6IOOrWOkVbf naid1yUt7xpEA38mgKZLQrXNnRbdJ+RKG78oczbuQB91hBMaJEnkwTxfKqa/qLA76qzPOxioj52 Pwe22F+QpwO492HuvWvMXYEFGlM2jw8XopMvfhblD11hFwthL8Y3jjXNVM+xCv3GJn3FqnrMcLl m4halKuneRCcdO2t19ggF24k2xZdLsMZ0iKGQ6bBbuKVedELM6rD5hfqlQtPdqDIAY7sUQWBUvp DN64icrmpnZW9OaJkrd4krcwxu4tSjATMWDDrOACv77Mtz3geawhAn+yIUM3yt5vge5Q== X-Received: by 2002:a05:600c:1385:b0:499:5220:db3d with SMTP id 5b1f17b1804b1-499879a50afmr31079585e9.16.1786685668014; Thu, 13 Aug 2026 22:34:28 -0700 (PDT) Received: from deb05.proceq.com ([213.160.61.66]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815f20058fsm5914247f8f.4.2026.08.13.22.34.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 22:34:27 -0700 (PDT) From: Mehmet Fide To: Ping-Ke Shih Cc: Bitterblue Smith , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Mehmet Fide Subject: [PATCH rtw-next v3] wifi: rtw88: usb: route bmc frames via the high queue only for DTIM delivery Date: Fri, 14 Aug 2026 07:34:26 +0200 Message-ID: <20260814053426.2473247-1-mehmet.fide@gmail.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Mehmet Fide In AP mode every broadcast and multicast data frame is routed to TX_DESC_QSEL_HIGH, the after-DTIM queue, whether or not anybody is asleep. The firmware drains that queue at beacon pace, a dozen or so frames per second measured on RTL8822BU, while one associated client's mDNS/SSDP chatter alone exceeds that. The excess accumulates inside the chip until the shared TX page pool is exhausted (measured: 14 of 1803 pages left). From that point every host-sourced frame queues behind the backlog: authentication responses reach the air seconds after the client has given up, so no station can associate anymore, and the beacon reserved-page download fails the BCN_VALID poll ("error beacon valid") because it needs pages from the same pool. The AP keeps beaconing, so the failure looks like a silent RX stall and only a reboot recovers. mac80211 already decides when after-DTIM delivery is needed: it sets IEEE80211_TX_CTL_SEND_AFTER_DTIM on bmc frames only while at least one station is actually dozing. Honor that instead of routing unconditionally: flagged frames keep going through the high queue with the MORE_DATA and HGQMD handling introduced by commit 076f786a0ae1 ("wifi: rtw88: Fix AP mode incorrect DTIM behavior"), everything else leaves at line rate through the AC queues. This partially reverts the usb.c hunk of that commit, whose unconditional routing is what lets the backlog build up. On a bench AP (USB2, 20 MHz, WPA2, hostapd, a Windows client driven through disconnect/reconnect cycles): reconnects fail 0/5 on RTL8822BU and 0/3 on RTL8821CU before this change, and pass 10/10 and 5/5 with it, with the page pool staying healthy and no beacon errors logged. Signed-off-by: Mehmet Fide --- v3: drop the Fixes tag (Ping-Ke), reverse xmas order for the declarations (Ping-Ke). v2: honor IEEE80211_TX_CTL_SEND_AFTER_DTIM instead of routing bmc unconditionally to the AC queues. The flagged path is the code 076f786a0ae1 added and is unchanged by this patch; I did not have a client entering powersave on this bench to exercise it explicitly and will follow up with that measurement. drivers/net/wireless/realtek/rtw88/usb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c index 64e1c3420..43b9cdb4a 100644 --- a/drivers/net/wireless/realtek/rtw88/usb.c +++ b/drivers/net/wireless/realtek/rtw88/usb.c @@ -560,6 +560,7 @@ static int rtw_usb_write_data_h2c(struct rtw_dev *rtwdev, u8 *buf, u32 size) static u8 rtw_usb_tx_queue_mapping_to_qsel(struct sk_buff *skb) { struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; + struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb); __le16 fc = hdr->frame_control; u8 qsel; @@ -567,7 +568,8 @@ static u8 rtw_usb_tx_queue_mapping_to_qsel(struct sk_buff *skb) qsel = TX_DESC_QSEL_MGMT; else if (is_broadcast_ether_addr(hdr->addr1) || is_multicast_ether_addr(hdr->addr1)) - qsel = TX_DESC_QSEL_HIGH; + qsel = (info->flags & IEEE80211_TX_CTL_SEND_AFTER_DTIM) ? + TX_DESC_QSEL_HIGH : skb->priority; else if (skb_get_queue_mapping(skb) <= IEEE80211_AC_BK) qsel = skb->priority; else -- 2.54.0