From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 0E3944746DD for ; Thu, 13 Aug 2026 21:44:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786657453; cv=none; b=CZOla5+vlCz3TI5+AYps8XvBiwPRrIVwJ3fS0BAjWVFbv6x9ghMzitooxDyBlMZHYM77wETWUjTzyrn20pjyINg2hcvlHMn2XwRR9hCptO+aVDkWaa96xZhCjgY+q1uQNqZ5ZHUkxdYPqLLHotYhWnnPyOzSjN3lqmG5uVzeB1c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786657453; c=relaxed/simple; bh=xXLOP676OB4EJ92wd17Rorty+J/yoWS9Ku/VxGH1O8s=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=lCLYcKMOslu6hgYZ1gHjFHlCX8W1e/KFJZNbGBGTbV8auwDy1oCMVKZK92PqGQS+F7goH3L6DqAGenFzhvZYFKwH6NBB1v3SMM2lf7i38jlZ/j3TMFW/Da05+WdnfJ1tH0iPVUlYQVNpPNU2DxFgDXYjQruKqCmYLOxszc3JWhw= 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=VsT4K92H; arc=none smtp.client-ip=209.85.221.44 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="VsT4K92H" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-47de0093c42so261597f8f.3 for ; Thu, 13 Aug 2026 14:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786657450; x=1787262250; 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=yi5qUyFjsWwIUVgVZHFCdwczIV0aqX/dQwzvLrxSz24=; b=VsT4K92HWAIW//6k5n/XDKwYTEvepodD/xV5e6fKIybIRpzXz9VdGqfY+eIhnQTktt d2k+YECjiVeJo8IFq9KtLnEgnGA95rVwYG8dtZbyEAQfvvKsZfllHTVgvQmVxTADQ/FN eFmD067QegIoFMxIT1qQ0H+LKXJVVIlyZSPgtnAJofgDfHmZclaibl+8h7bzq8Hsbk61 j4zf8pnuYLHiqWl2W7m+vXPduWRsoVahDfHNxVL5QvcYlbuP4qgYlJHCIlS26r99vvFx 0ihvywAurV7TSnhjULXgEPUX+WQN7jAsKn6pejAXQs6jzseJEJ/nOmLY/W/G5nwRZ11f pQ7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786657450; x=1787262250; 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=yi5qUyFjsWwIUVgVZHFCdwczIV0aqX/dQwzvLrxSz24=; b=Dxv1Zd+1gU9I8+Pc8Zply2tUrvtYQnuXILoIJ7vkko+F0lJ2Emtn3txuycRwqd1lTj Gww9l6EEBO5vxZR2OAMjFVLBXvYK1d5QnJHEGveJYzz4EY4hb7LlK/IEivScfh5Ohh23 DNdfpIVpYMOc5o4nrq1q2kD3t30GhlVa5Udqf+KV0YY37u7unzbvK/1WwALHjHcWRnwD gRunFY9Ht/rWioY67ZippVJw7AFk2hYjuYQ5E0ZSY11SRXUNbA5+9BE02W9zASHqhAfi UdNyk1PVFNI42ISYHiKmM4pN1OPMxZoy3noX+afpRRvVVK2vCfXoFDSXgmUXh5JneQ1x DVHw== X-Forwarded-Encrypted: i=1; AHgh+RrJQoqwt03PJp90bvShm7/OpiAS2ngGFeQOUcTBCE7iAwaDKyQWxZ/5ugfcMFYqDPLPvAqKd6DM5SJf868=@vger.kernel.org X-Gm-Message-State: AOJu0YxBJB3p31rg1FNihS+KMTWx+K1ayHuKUlZvs0ie/ICkMErR01fK C6UOwsAScF8rIyqbGz652gJ7dsijXC29qjzf8fwidyiXm1jzs2xVJaIG X-Gm-Gg: AR+sD125p11CsA/bfM2jfEcqFq5JwDHUquZRls6OKzgo8occesmIz7TRsA5N0osPT/k ySRqS4lGxr3e91Jn9KTKIs8Hn1+PDbIjdh/ycpr4TWTEpChal8wh7JsOEwjWfH9RBgaEVCKNLaK JvaRCWDnwL+P1ZQ6dOIrSlsn4SEFmB5YunFEiY9/O2GYtw0+mZ1CIvItKo21fsNGpxUbdLnubtx KxkbhGxBebpAN42qHSKQOaJfvZ6cEOIhaEpQ1q7wWcc+giiavZKvRaodNf17j4AvPakQXWXT1o8 OnJs10cSlu1M+pSL2ep7kt1D9cG5LvRMzAbSnC1Z4Yn64prObGcsihGq5S2IzrMJMrNgFTOZXUk iXJHS31GQ9RIRvORV1gDpGgEQB9dikSJnmOng4Pj0eOyZqs6Q8JmOpNMVZUtVm0+gfC4WBtt1lm WZxm0RVN54KeDVOi1EuiLgZN91sZU8SsyspV8vWlUC0Oofr38FN6Jjl4e9S28lCUp1bw== X-Received: by 2002:a05:6000:2612:b0:47f:c648:e265 with SMTP id ffacd0b85a97d-48160758afcmr1569350f8f.17.1786657450038; Thu, 13 Aug 2026 14:44:10 -0700 (PDT) Received: from deb05.proceq.com ([213.160.61.66]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815f219d3dsm2627094f8f.14.2026.08.13.14.44.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 14:44:09 -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 v2] wifi: rtw88: usb: route bmc frames via the high queue only for DTIM delivery Date: Thu, 13 Aug 2026 23:44:07 +0200 Message-ID: <20260813214407.2438670-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. Fixes: 076f786a0ae1 ("wifi: rtw88: Fix AP mode incorrect DTIM behavior") Signed-off-by: Mehmet Fide --- 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..c0990c125 100644 --- a/drivers/net/wireless/realtek/rtw88/usb.c +++ b/drivers/net/wireless/realtek/rtw88/usb.c @@ -559,6 +559,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_tx_info *info = IEEE80211_SKB_CB(skb); struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; __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