From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.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 5B2C7368296 for ; Thu, 13 Aug 2026 15:52:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786636379; cv=none; b=IIGJyO5QFxGgiFQUDdHXDyF4Q+8rHu0P1Vaopb+ppyf/cjQZmC9RULt8teBGo1+nvwKM4SFdIZ/sM0tHWEAA0z7stxWMY8IUo1ZLVoTzmUGmU30oGpa2CO8V8yFWwadEhYsJvZwpTNQAHtuFfOGu5CYcPb2VyS3MTZiYSM602YQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786636379; c=relaxed/simple; bh=Lf0/l9SjmdszMnvIlBnumgO1zpkWzhYliVln6iJoC7I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=drlM5au+iFhQ6YKXrHyqyvqeBpCGI7UDpqs5EKFPUJlp1uoGeqSP7Rv2lb8DSjYL3OOSanmgJwPeR8UHG+cXnbvDXneU9SOcbmiU/Yg6J9JxsPAtj0YYCiokRfKQnB9LL0CHfoHJ7xUqgqhNfcvNVLR/fej03i6Q6WQ7SOnRN3g= 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=i/9MPtXl; arc=none smtp.client-ip=209.85.128.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="i/9MPtXl" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4956242332dso666765e9.2 for ; Thu, 13 Aug 2026 08:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786636374; x=1787241174; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Lf0/l9SjmdszMnvIlBnumgO1zpkWzhYliVln6iJoC7I=; b=i/9MPtXl1Za+VJ9YAMM1FwLSrKjH9W5MqJffhXfZr+Fvhwt6x0/umXciO+GtE58h2p +27kICEwEpEhce/RA8aYdNjzKMxFi2lx6EFuRPfFltMcM2unz2jiCNuEZdc/gPk4QGXH Bls/hCx8aFk/0ki0jMDEzZ3mM8wzmcAl9x5QNKoud3FXSCPglYlsv/jVRKqgnSUBUqim LKGiadpiixtABHWhv6w3tp5ZqLxrDEyw7Gq4AE3Chwze0fKkvxAtCf5FzO0Cp2lELmQ1 P4nAC+xTPv5YqdXYWPY6mgiYJj+8bbag7eSUszwcURlsXt4L4N70pK78f2aoLZ+ZyYMk 1uVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786636374; x=1787241174; h=content-transfer-encoding:mime-version:references:in-reply-to :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=Lf0/l9SjmdszMnvIlBnumgO1zpkWzhYliVln6iJoC7I=; b=IvIjN7mcHo1MD+v5fn7ATw6dyWCFT5HeH/UqVctJUfn2Og1ePD1ehXPY12xz24lDMz M87zO/hesN6ewdDGhYvSMtiDstH1oKPsdNnsbisZRcN+Si+ot0iOtYe0xFnNg7JhMqj0 vCAOgnRoacb+Hyg7raxuIeVRWU1n5vg3/khS+43tsIxMsuCxNj5WfGC7NF9ahT+3hlBs Q5IysnvUqQ1VBdimrXoY7q7ULki6FUN7gnvYUJp3OANeZPWksNKU5XhAuV1F0l9JVpnd ge2WZL9YqUNpWt/WQVjNK6mCqZrRI45T5cu7q8hSNHzvAvNbYkz3WEUbc/99JEYGysVx HrFQ== X-Forwarded-Encrypted: i=1; AHgh+RoDeTxb+7tj5SBlvsnx3XeEBzi0Kh6+fy3QMdxMwDWDiaSgjDyupkXREDzs1wCP3y+DPopT/XQZrzqVmxY=@vger.kernel.org X-Gm-Message-State: AOJu0YwvMjwtLkIXNOggRu8lIvFVqxgr5fdPTgpPKiXLYOLbm1k3LF1f D6LcUpNSpkjD3tquvO4CCQvvxVm8TW5bKPDjqhda//bZvrTT+E1s3UeQ X-Gm-Gg: AR+sD11WMKv1zj5A4Tfhp+dWFr1yYCOgn3UZu8+09eepfTo9K0P++CXT9Bka6ol+Iel 4/drbuJrQ4aT1WeSRXnvppzhKbn5dl/TtFOHlJH1NDqp3qrjycolZgYpFeREuMx6W/FTkipK+yK Gso9hKE0tRD/MVnw9rc1gAsjZBIUZzY9EGAmO6l54pB71soGvuTlWnmD8CLAy7jizJDH76OQj9S uv62NjF8CsiA7hwcEZmNkU3yLAH23slv/C+/7PnihI5UhpP1B9VPzav2tCOoXme/rosehtlG0do /zK+PjtLpFlPQF0cXQHovThbZk8arLKU8DcuxIkjvlPkOd6Lii3T/Xrg6bNiMfQfTkyHIsKNVFX r4ohnANIfC4QSv46Pw/A98zmNw3iUPkReejqAr/QZDvlpmhKjdvqF5/HXQIVeLXpYPTznLmELxe t0u0ttwfGtgABrfRdL78LH1H7oXe6s2gozN6wmtQhFcC/xuCMMpmnBrtE1k4Tv45c4vw== X-Received: by 2002:a05:600c:3b2a:b0:499:78b3:7b36 with SMTP id 5b1f17b1804b1-499821c9a1emr75650485e9.11.1786636373908; Thu, 13 Aug 2026 08:52:53 -0700 (PDT) Received: from deb05.proceq.com ([213.160.61.66]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815f21a24esm326560f8f.11.2026.08.13.08.52.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Aug 2026 08:52:53 -0700 (PDT) From: Mehmet Fide To: Bitterblue Smith Cc: Ping-Ke Shih , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Mehmet Fide Subject: Re: [PATCH rtw-next] wifi: rtw88: usb: send broadcast/multicast via the AC queues Date: Thu, 13 Aug 2026 17:52:52 +0200 Message-ID: <20260813155252.2265589-1-mehmet.fide@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <4bb13bf2-8588-4235-a1ec-b82e6668c982@gmail.com> References: <4bb13bf2-8588-4235-a1ec-b82e6668c982@gmail.com> 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 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