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 5C1243019DC for ; Fri, 1 May 2026 21:28:42 +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=1777670923; cv=none; b=tSmHdgm92eHZZ7NPr0sle5gSBWZbkXr09U4wayeGxiGG6DZ8EtOPqbyED4OQ10tHswjMz7vB2LdVg362VLYpBaU32FKoDcj8aMWHMF0DZMiOIfKMwN8gfW1pUGzkPhj0PaA+Yj8prhQgLUFdguyb/q4LCWUeKLLZFC+9PmFhPCs= 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.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="Y+DhV/62" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-488a9033b2cso20174455e9.2 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=Xf2hRSbxj96KkMRpTl3ON6r0cFNd9kiWHo/g0jtKsO8jczyIyY+AKEa/mnGqyC8wKz 2npJNLF23fsiGOIjYBkdY2/xVPAZbp37I2wiJR/nvk3Zm1m114yTC/w4RH6GhbyfoUYK E2Gi8IwvpUtXQhWPCt9lYPFZkNk0Kw3KxkUrt7CxPCbvtS91hxm6TZE/YEUmWR4vyRoh sWXl7HYB/CrR1KcpxAkaST64LdeIyTlaaDs/JUroCjsbN+C2Kw2brtScXVTtwSO6SQgp /nAaB1RWKQCtlMVgDoSijX0UsouBlpPV92sGV5HI+fq8O2+c5hpNIrMFCCc/cSf3gOyS u/aQ== X-Forwarded-Encrypted: i=1; AFNElJ/SgCxqpqqGoKnMIQCzGuW6eYtX/QWIWtrifJe4FRKmRfdd4ujQRR7OxDsIwqlBGwoCUhjj4oI=@vger.kernel.org X-Gm-Message-State: AOJu0YwJ3rp0cX7V87XUguRY4eNv0DzTIe6swkvUAbCP0XLz0iz8hknY 4KNnTDUiBH9gT2A4vci+tfMrQ5nuZqhkciQsLvLMciA1qsVgZQynKhA69xIt1A== X-Gm-Gg: AeBDiesR9YCzKDAIsuKaRJzDKphYueCEnaAEVPo+yazmSFxwudgMJ/aWuHCBYpQhaTI RWsF8LmB5DDbTevnoggyPBh2PZfZCyTk9JCfN6JD1AKIl8HILIx1z88eRVef0BgzVbvRvq1NLbs Nsdo8gFShe11kejXQbjflraZlzdFK5VBlcfELp3MtRs6V578RrFWZEy9fP5g3mHTnX7usaMWHzw Mq840ebcDPsByZbSn99E/SkyI7sdg1RaUIyf6Z9JI/WkXTcUXtylnyDVWnUwl+g0+Izi7hBP5fC fm7sS2L19397Q+jGcmtaDchQJcMUv/1Tvwz6FdgrJWj/E1ZRWq+eIxLX/2Fs22HkwRI4sm16OD+ Irm6wvDxh8wDw5JIKWsINqjb/v4r1QDfZ8dgenAe12jxfznjtGv0nwqsGckbTXcMmUxB9QOFtmB o8MD5Mm1nTVvpSGsWPusmy0HUglVUpYc5X5xvlFgnh 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: stable@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?