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 7A5AB38F957 for ; Thu, 13 Aug 2026 18:34:44 +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=1786646085; cv=none; b=iVLKIIjfCdyTwrVKGOs/A+ljAldLVE2F3XywJaDpbt1tNoAFX8/elG8Yul/NY9xJtHak7Pa3oY2wwLFheMjBOC3zRk0jDxOHDtetlQ6CymwNLp7wPE73PkUB3x1rrsydzsSTczqgRRLsl3XQTKlaOX11WO0meAFdyEZG5uwR5m4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786646085; c=relaxed/simple; bh=DHFZ2TaJOgchJ5PIo/X8b3TeXaT3TPk70S1lgfWB3Xw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GoT8p0FQDaqVpqUSrIbPgpFc4m6kA2PPPou8bBVqbTX+JNOmYRxYyyfvrSAA+fQ5Qz/K7IQjNZysEJ12Yf+UbvRI+p/RYYVtX5Jm1jOlmnf1sCjNWPN6cN798uVAo0EFo/P/nQhEFAKQUtvD8tOTzikbBSFPuOUoImuMeDOT77Q= 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=SBPNCcEY; 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="SBPNCcEY" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49800c6a846so2378655e9.3 for ; Thu, 13 Aug 2026 11:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786646083; x=1787250883; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=VhF0Xbpe0vf9q5WFf1uUEKSaWLORxrvQ33nYU/aKtAk=; b=SBPNCcEY1l/Xq7vpa1sHnjpCP6mRoPhbeoQz8QJH3aGStEU/7uhzykMss3B5G1QnV7 4BKCbPJ2cmMFDWSDqCCsw9nJb7VBH7UbyPgsvF0nrqsaJjsYN6T9kyeHbBcD9tzakXKF rEg9rRYqIzg59oKC2T2TSGCZKDvBnSsTQmHbONuHReCAkYJO6bNTXh65hmgFAOwkD5KM 8qvb3680swrschS0m9+Q0WWs1Hdlsz0akansQjqRbwNIaY4FCYOhJ2uzs4QLloAiLtU6 wHmADzlDdrEJ2/xMgAeghqo0BLbsfdPDOY0dIeFVo29sGUmwo5ft9lPs8e4azKCf2+KB GfhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786646083; x=1787250883; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=VhF0Xbpe0vf9q5WFf1uUEKSaWLORxrvQ33nYU/aKtAk=; b=AU5SJ09oIR8n9kL+Vba+MhDI6/BWbYfE7O8IJX8dmQiWX2eO1LKKz2PuOlSKESbId1 v/v8ocPBgJy8SXVA+Kqz9KCOayStyab6k1lLnLlwXCxbB8i8i1wPTXniAQo8UOybAREs 28e0p+jKOlAip3CR3JKvpDrW+kzVAZKXLnxLNl0OJjtO0APc64cfcwZDhgRZIlPbmON9 omHr3ghnw6ktz7m277mO1TcPprfUw58jo1HSBbR/g4joNkXIEiL3yrIdhn2Zp6zxZzR5 J2w4Een5HTsRZGNhDBtwvZBjFx1CeT65x+CpZ6fL7VYG6VcM3t/LcJqmpbasOQTTijtJ BPvQ== X-Forwarded-Encrypted: i=1; AHgh+RpiC98vKWLu1J2rClAw8X6zT463+O8HW/blqAV7wj7u1WR8Puf6VJoNgtQZXlDxpCV6cCeH3WsQHnG++lI=@vger.kernel.org X-Gm-Message-State: AOJu0YxtcChK6uY4Fj/yfFY2bXSyWEQFqRluwCTxx3JdnTaxVvtaLXc7 n/jX/vCEy/57BISO8dgJm9hB0lo5i96ucy8AXlOWmJlL9BjtPcKakFo2 X-Gm-Gg: AR+sD116+PM8qqNvvmdZ7Axb/MkXbVyvxCcsm6dIdli5S2JZjtz6btKrGk0n2zGYZ8e ql38T2BBbQbjujGeVv3gPJbZ34yE4POGlI+Vak5yZrV3is8kW+EnrvOcyUPC7nQCWgv8zdnJ//Z BSjEL5UkeCWEYUfCNaLL3043Kqb1SWR9YbimtH9jvDm6pHv6IBi22+lG3RbtkQ5FUF1EuKDGueB NELgKlDwIKSrUmW2m53G8wuvtWXPeYGAV8T7PpL4Pbg+p1d/w6QgmPYc883X8/voRcxNpAU3sHM WvWN6HQ9pFs92tFuZvmx8T3b0MmbAL9Ym6TJIAAlqT+FB3diKk3GXD88OGTr3X9QLIOvfSsE37G Goe1nPsafZ1CGHdzgGicCaiWNOZyajUnGzl44OiArW1twq/9CTRsLFDmM653bQq1stbXYy+42tL J8wrPtoKud0wchoFm63hiHvjZcBOPaB21zO8nz0IBGZJOb4MRhJn3iuPuMZhIRsuXN7+idoQ== X-Received: by 2002:a05:600c:6289:b0:499:84fe:ca8c with SMTP id 5b1f17b1804b1-499879332e1mr5414995e9.5.1786646082473; Thu, 13 Aug 2026 11:34:42 -0700 (PDT) Received: from [192.168.1.50] ([79.119.240.229]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4815f2c46besm1159536f8f.31.2026.08.13.11.34.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Aug 2026 11:34:42 -0700 (PDT) Message-ID: <12eaffd0-9d0f-44bd-8163-d05b6a3df611@gmail.com> Date: Thu, 13 Aug 2026 21:34:39 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH rtw-next] wifi: rtw88: usb: send broadcast/multicast via the AC queues To: Mehmet Fide Cc: Ping-Ke Shih , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Mehmet Fide References: <4bb13bf2-8588-4235-a1ec-b82e6668c982@gmail.com> <20260813155252.2265589-1-mehmet.fide@gmail.com> Content-Language: en-US From: Bitterblue Smith In-Reply-To: <20260813155252.2265589-1-mehmet.fide@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13/08/2026 18:52, Mehmet Fide wrote: > 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 Could you check what the official driver is doing in the same situation? https://github.com/morrownr/88x2bu-20210702