From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-102.mta1.migadu.com [95.215.58.102]) (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 73CC747CC61 for ; Tue, 1 Sep 2026 13:49:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.102 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788270577; cv=none; b=UssdooDAU1dMVuWnYpO1GtD5ImXTT61Ndmbjh09cyWmHE/LK9q2qJWQ1MyGmmWgx7/+f75BI1YDQcPNMCXME5XZN7/VRVKPMjdiXXyu3DKqJb57xCVOyHuMm7NtWAHmxN4kPEL2MDJyab5wICCfITsYofSdo/+VaKFANoKTciGs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788270577; c=relaxed/simple; bh=8QFSnlpySFykmoc6yP1oqqE80w3/ep3oZQ4c2DH1o2c=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=kUX6/ygklfMgDfAVUxf166nG5cltF910zPOfarkL3yp+Eb6+EHjjoFyu4ME5pwB5ArqUm8JQ+dTcYkhASse0vSxuSpOuVDCCVPuoSmtRGu7OfoXz8eu8IG08J0aujwI/yuq+d9z3L+LXnLN+kb0eNhBj4I1Qmf5eGAg4GFd7rRg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=J2nMIk0u; arc=none smtp.client-ip=95.215.58.102 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="J2nMIk0u" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=8QFSnlpySFykmoc6yP1oqqE80w3/ep3oZQ4c2DH1o2c=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1788270569; v=1; x=1788875369; b=J2nMIk0uDH6PGukag9s3rj8JytwxaY2785gBuaNtbmxpWbkp4tMAzlSjfhC+CRpqtmwKqOVT 85SvJZudDRyANBEsb+771w0LfDTk6dqHiRfXFMQTgaesDkGUI0T0BaX8wrVRaQP0Xwafzl88R43 A/sHm3MW/X5wcVSII1etqm/I= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id 7ef7f32c45b88611; Tue, 01 Sep 2026 13:49:19 +0000 X-Mizu-Trace-ID: 7ef7f32c45b88611 X-Migadu-Flow: FLOW_OUT Date: Tue, 01 Sep 2026 15:49:13 +0200 From: Luka Gejak To: Ping-Ke Shih , "linux-wireless@vger.kernel.org" CC: "linux-kernel@vger.kernel.org" , Michael Straube , Bitterblue Smith , Peter Robinson , Hans de Goede , luka.gejak@linux.dev Subject: RE: [PATCH v8 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS User-Agent: Thunderbird for Android In-Reply-To: References: <20260825163314.1590-1-luka.gejak@linux.dev> <4866D935-FCC8-4F24-9C05-8678DCB22533@linux.dev> Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ping-Ke, On August 31, 2026 4:23:48 AM GMT+02:00, Ping-Ke Shih wrote: The probe_wait_ms test you suggested has run, nine hours in the tester's poor signal environment=2E At 2000 ms he saw one "Failed to send nullfunc =2E=2E=2E disconnecting"=2E At 500 ms it was one every twenty to forty sec= onds=2E Same environment, same driver=2E The reports are late rather than missing: txrpt: nullfunc sn=3Df0 queued wlan0: Failed to send nullfunc to AP after 500ms, disconnecting txrpt: nullfunc sn=3Df0 acked after 810ms The frame was acknowledged and the link was alive=2E Nullfunc reports run 400 to 1000 ms on this chip when the link is poor, against 0 to 20 ms for management frames on the same hardware, so it is firmware retry time=2E That also rules out the timeout path as the mechanism=2E It fires 2500 ms after the last enqueue, well after mac80211 has given up, and a build that handed the frames back as not acked instead of dropping them made no difference=2E The sequence number aliasing I raised does not show up either: every instance had one frame in the queue=2E So there is nothing here for the driver to fix, and probe_wait_ms is not something a driver can set=2E I am not proposing anything for it=2E > But I feel this case, using ieee80211_purge_tx_queue() is equivalent? Not equivalent=2E ieee80211_purge_tx_queue() calls ieee80211_free_txskb(), which calls ieee80211_report_used_skb() with dropped =3D true: that settles the airtime accounting and frees the skb properly, but never reaches ieee80211_sta_tx_notify()=2E Only ieee80211_tx_status_*() does=2E = It fixes the ownership bug and tells the connection poll nothing, which given the above does not matter=2E Still worth doing on its own=2E I will send it separately, no chip condition=2E Best regards, Luka Gejak