From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 6543F34A3A5 for ; Fri, 1 May 2026 21:28:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777670923; cv=none; b=HZ6db+nxsQ2qoNRzcOajadA+5yrMVF5tIV5xiFAVqZbq6s+Ov+DT426Frrzq6F3Bl6/mSYBuxqUkV2vjCrf1+KTGmeWENSHOGs68Lx9Obwn7+mPGEH0XRgywfoXtIiEe46YDotUzIMPr2bVKdSBzX09M3lbl74BSNptnWzUx7VU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777670923; c=relaxed/simple; bh=Qwwy+DUf6iPTgesOu7Pi9+zFZbkCGqSm+hqB/dFkyOI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CZV85fJJAYSzywsiRbRYrlGfokD1y42d+PTXfmolAHWo0rGm4j+q/aYgT44cSDFiWOnbPzmIqxGwHVykaIrEu9zBHmX+hxsbiG/IGkvfglS0gnMblPuhoc7+kkIXdzsGnk9EyFpi4oiSg0dUR6nUCVMlipKk8F1Gg+xF9nzg1TY= 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=Y+DhV/62; arc=none smtp.client-ip=209.85.128.53 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="Y+DhV/62" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4896c22fcbaso15660125e9.0 for ; Fri, 01 May 2026 14:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777670921; x=1778275721; darn=vger.kernel.org; h=content-transfer-encoding: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; bh=q93wGvbwq5yzcLn4p5cmncjwFXks3Eo2eFbWnIa1BT4=; b=Y+DhV/62fEsNG9HMuiV/3+W6m9eu3hxlZJji5WoAw6w9Ih0m0pkLdtxgjTVEmEp7+N FcWS17+1Me2Wn0egz0jYz3VEgUpAdsRgsk/KI9Z9ZYGzfyboMD5nmYxAHMgI/F+e5Y6f 7icya+ljIwHIG3vrTEeiCr4kifW8BqBrsv4k+GTZdPPlaSMYmrGUpSphbkyPThTn7YKv PGxgEAV7Rb0hV7y9CC6z4dllebNQVJI0TbM1t8vuJE23xWEggvtiFErr3nLg4Ju1rleJ SLlCYQ+yf9CPb8YsmW83jR+Cp1AX5IBvQw5Eis4LeICV758wIaam/4rNtTepCYGV7fhe xMcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777670921; x=1778275721; h=content-transfer-encoding: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; bh=q93wGvbwq5yzcLn4p5cmncjwFXks3Eo2eFbWnIa1BT4=; b=HbZOSrVrAqknDHEpdGVTin5IDCkQqSy09VQKLaweiEOlA4R3o2dDsoJNs9DGwfRIeF eVlj6EYxXviCOeBqHTUKd81vZ/jH6sBX7Y2V8ju2R00sLlDTWF2Li15VwTdvuYBixY4w XQWfjOGbdIjmwteFMkqIwC4uJznUAWB2hnmktU6MQMkWoyhCggqV0gvRMH/fMzpLgOqS W9puh5KboCrXHqy2d57JvFMigvgSv59RlFCUXFQBr/926ba4eYpQUF0phxrruMiFtgg2 z/QzJwpYyK27q37k66jjna37Fmplnc64evycNz7JBQkbos41jX0jId5rQ7fH+5tZLbxm zGPg== X-Forwarded-Encrypted: i=1; AFNElJ8CI5HC4swSqukr1D9rvvrszv4NpAKzZ+BsLu3uwtDUJGGl00N69jaV2oT4jKCQ6OKsBqEtIFKii6/TE0Y=@vger.kernel.org X-Gm-Message-State: AOJu0YxXLUNxwtI2gIZfueDHokpKbmXlHErg5pqRqJto0EcAAZHj1ILP DszJ8Qopy4BmPFkn++lS9m6LdNxx5FulqJaFe/ldYTQTtXMYT6ba7And X-Gm-Gg: AeBDiesru6dJCfjpKGwbv7+++rLeSVvv2lqIDB+90+5Hdgv9ZbQqM5e1GszJyLNMghW aqtsMpOBjD1qdsKc7KstWW19Gm2oEjx7aQBNCOjHZvbpHot4dqlKAoDIFf+ujGx6nyS49SqwVuG NugSkHVH4Bvm/IkPSCcw2SKELbXcoIb5MIcL7MORbnJvijQUHSCNAy2FTuh+9ikUuXhd9T0zmVG MLvIEXN7rHWPaL4fSME/8Uxqm6JAaDgPUKuZjBBMmn3nH7J/K6WIsjePAxHWkrUXxcrYmB75Z+o Z2XEfpCV++gRp9Ejr4ngKQvQTJJa0NrZCnwJYqvps0c4VYgrB1i5H1zHL6VMkD4G1wNdZKGpdQ/ HDBD9fBvuYlt2y3BmAJP4+5znI1uIAy9Ga+R8kWwYwX0KQL5GpOicqZSV8q/F5VXG5zzmUXC+M5 nmT6m4GAm2KrrfhMobCHOEWTSYHbmn2OLSK/xVBg9d X-Received: by 2002:a05:600c:c0c2:b0:48a:76a3:2b9b with SMTP id 5b1f17b1804b1-48a9865ea56mr8151665e9.17.1777670920716; Fri, 01 May 2026 14:28:40 -0700 (PDT) Received: from [192.168.1.50] ([81.196.40.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a81b99127sm149092285e9.0.2026.05.01.14.28.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2026 14:28:40 -0700 (PDT) Message-ID: Date: Sat, 2 May 2026 00:28:38 +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] wifi: rtw88: increase TX report timeout to fix race condition To: Luka Gejak , Ping-Ke Shih , Kalle Valo Cc: Yan-Hsuan Chuang , Brian Norris , Stanislaw Gruszka , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260501150402.227788-1-luka.gejak@linux.dev> <72f6fffd-bd77-437f-a9d9-6a542a8b365b@gmail.com> <6CD170FE-CAED-4B91-AEED-A1AFB98FFE8A@linux.dev> Content-Language: en-US From: Bitterblue Smith In-Reply-To: <6CD170FE-CAED-4B91-AEED-A1AFB98FFE8A@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01/05/2026 23:46, Luka Gejak wrote: > On May 1, 2026 9:26:30 PM GMT+02:00, Bitterblue Smith wrote: >> On 01/05/2026 18:04, luka.gejak@linux.dev wrote: >>> From: Luka Gejak >>> >>> The driver expects the firmware to report TX status within 500ms. >>> However, a race condition exists when the hardware is under heavy TX >>> load and is simultaneously interrupted by background scans or >>> power-saving state transitions. During these events, the firmware may >>> go off-channel for longer than 500ms, delaying the TX reports. >>> > Hi Bitterblue, > thanks for the review. >> >> But power saving state transitions should not happen during heavy TX load. >> > You are absolutely right that power save transitions don't happen > during heavy TX. The issue is strictly tied to off-channel dwell time. > I reliably trigger this on my rtl8723du (USB) by forcing background > scans (iw dev wlanX scan) while under heavy iperf3 load. The firmware > goes off-channel to scan, which delays the TX report well beyond the > current 500ms threshold. > >>> When this happens, the purge timer fires prematurely, dropping the >>> tracking skbs from the queue and spamming the kernel log with: >>> "failed to get tx report from firmware". Dropping these tracking skbs >>> prevents the driver from reporting TX status back to mac80211, which >>> breaks rate control accounting and degrades performance. >>> >> >> But mac80211 doesn't handle rate control for these chips. How much does >> performance degrade? >> > > I understand the firmware handles that internally. The performance > degradation I am actually seeing is TCP window collapse, as the host > stack interprets the dropped tracking skbs as packet loss. In my > testing with iperf3, throughput drops from a steady 80-90 Mbps to > near-zero for nearly 2 seconds following the scan before recovery > begins. > >>> Increase RTW_TX_PROBE_TIMEOUT to 2500ms. This timeout is large enough >>> to comfortably accommodate the duration of full WiFi background scans >>> and sleep transitions without incorrectly tripping the purge timer, >>> while still eventually catching true firmware lockups. >>> >> >> rtw88 supports many chips. Which one are you using? >> >> Perhaps provide a full description of the problem you encountered. >> > > ... > > I also realize now that globally changing RTW_TX_PROBE_TIMEOUT to > 2500ms is too heavy-handed. Since this impacts all rtw88 chips, > including PCIe variants where 500ms might be exactly what is needed to > catch a real firmware lockup, the blast radius is too large. How would > you prefer I handle this for the v2 patch? I can either implement a > more conservative global bump, or make the timeout dynamic based on > the HCI interface so USB devices get a longer timeout to accommodate > the bus latency during scans. > > Best regards, > Luka Gejak No idea, I'm just asking some questions... Actually, I have one more: what version of the driver did you test? My quick test with RTL8723DU doesn't show any "failed to get tx report from firmware" when scanning while running iperf3. Does it take a long time to trigger?