From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 DE43C41C31C for ; Fri, 1 May 2026 19:26:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777663599; cv=none; b=mwZAEY5o2uFGE2YA4orwq/ZEwZFcvRmpfknCmwetEsA9y+h5A+/WXrzm3G5DX08wrX5e4oCSwGFXfuDNbCL7NMUK6NcfJdfgDLUG9kAgs0U1LXOaHpzAgaEWgYPOtHf2NNBAE++6TQw31/9BgEorzUAU93SL5PjlgzLvt5MPUEE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777663599; c=relaxed/simple; bh=HVuL/IZWSvdhZZkkQXpKjZZJIBtOavjaVaByvGXjaNw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=F62F2C9x9FvYtQqWHExYSAbHvhXXsFl8eFm4pvI7iMhAKppR3ABob2Vr+aTd22bmcI0HFTd8vNkYWUAxm3UXJTduDqfnGG4/W3rzJZ3UB1Kq4/tQ9V9g0ad/N/yzhZhSXA0hAWMxBBPgDensYbu9v5II5NrWF9xSERnyQIG1DMk= 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=JPAaRvsg; arc=none smtp.client-ip=209.85.128.50 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="JPAaRvsg" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-488a9033b2cso19626365e9.2 for ; Fri, 01 May 2026 12:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777663595; x=1778268395; 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=KV4kSIiY3A3IMB/1Fwk7IrL1FCT6zTF9wEUbB3puRYM=; b=JPAaRvsgOtvGbrYyebgx78TvF8ih67ZpLcmLCmJWdopIkeqsKViuOKqY0nbQSks19V slY93ogWrYgxQuYMgfAKxbWgC2WtfOfVxxxkQyeqKTqwTF7h9qGXrN8o+y/Q6crpfq7c Ubd90S49aCVaDv9OhhMUfMaoypeNSv2KmUAJUfSpK4sj90pR7+vGz6DSzCQd1px9pAdw RdNlN1G0M1MUX8UayEslQH7ec6h3A+OgKWV8zuQ+FZWFMuZUnXFl1VnKDmxAMyPp2stf 1MkVoENA19u54FylkFVTqadnws64kewGdLEcWXFnyU5aeLrAK16zE4CDiEBjaoyETfL4 WZ+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777663595; x=1778268395; 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=KV4kSIiY3A3IMB/1Fwk7IrL1FCT6zTF9wEUbB3puRYM=; b=LAPA4jNNcOqyRegknJ+lCBkIdpAe50QNyPpolzm28d6SOJGJdqBFSbeeFay4jyCbHt otN93qo650OGZsSIh6rfguVPxtFFn3gmKPKiZN62nq0jRbRm+mEjSZvW+mxy/8muyjgo bLpsqW5PtdkX0tONsUZNj2nLVDoqAq2jDcfdJOQMzrsmtaJA/bPC0bTRortkqsbR8+4Z HgfhLr8py/LA9wiOka3e2XZP48yG9697y4SYJOJEqDu169VRkzU/seKEXQJ/+Vo8gaNk HGLpph0YlNBHrnRMZfp5Cio9VdehiNaphY5AkPRRHbgVgsQ66+anYIWDAw7Wn/dusBxD L1ag== X-Forwarded-Encrypted: i=1; AFNElJ9sSHNzlQxFBHjzeG2K4q4+agjRx2ClM4hbm6SJ/X4CtM5OBnHwxILSTbvWrkXoOXaAqYiwhn5eoFdSmIk=@vger.kernel.org X-Gm-Message-State: AOJu0YyIPl/7dWFSwXsAhYwnbQbKXkw7tpHt5Gx2/Slmza61A1RRfi5I 7RU6Oi3EsotRzdaQ1r/amZpWj8XgQHXaHDEu2Db+01rjHyK2gpJDqpgV X-Gm-Gg: AeBDieuzy3oZmSaWejpTS6cXJ5aubWgol/Kxv0d8b+daedr5X92EzArJAYzp00A5vTG U5J/7eH1sBMNu7A2Nk1HHQSEPmvdiPNzCYeK8d/faLW+q8vs/T6HDb8RR3yABQbQ2SasYRC1taH 4baK4EPk6AU2kQgVU6B50tx5JIQP9ZYgVPzY1h570JNVjTxuuV1svUapT6qPnwK8UzHXHh5K+H4 2L+PlhXD1QwtRyADjnnaTn5PLj6cF2v52jKgut3CbEvvxLM63vU3jxejoI2eP+fwkDfWABAMPL0 alt1lMJ8TCjYqhpym71LmTkJ57SLr+gwMLRef8yjV/YPAcXyNGl3pAmOPkXXJNMUIwoSCh323K1 9ymjCa/C/fu+NlGsmy6zk/a7NDd2BBKMR4Tx8GObmzMRfd8bcHIDxxRFDQbUvKmK8DWt85AqURP masChoODMVVo49OfIUN/rv81+C/JPLjI2egq+wiEMW9xJ44Wp7ZGk= X-Received: by 2002:a05:600c:698d:b0:489:ad:7b5b with SMTP id 5b1f17b1804b1-48a9866e8a5mr6571995e9.24.1777663594868; Fri, 01 May 2026 12:26:34 -0700 (PDT) Received: from [192.168.1.50] ([81.196.40.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a82308d77sm171686915e9.14.2026.05.01.12.26.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2026 12:26:34 -0700 (PDT) Message-ID: <72f6fffd-bd77-437f-a9d9-6a542a8b365b@gmail.com> Date: Fri, 1 May 2026 22:26:30 +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@linux.dev, 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> Content-Language: en-US From: Bitterblue Smith In-Reply-To: <20260501150402.227788-1-luka.gejak@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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. > But power saving state transitions should not happen during heavy TX load. > 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? > 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. > Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") > Cc: stable@vger.kernel.org > Tested-by: Luka Gejak > Signed-off-by: Luka Gejak > --- > drivers/net/wireless/realtek/rtw88/tx.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/realtek/rtw88/tx.h b/drivers/net/wireless/realtek/rtw88/tx.h > index d34cdeca16f1..95d15e4f5d34 100644 > --- a/drivers/net/wireless/realtek/rtw88/tx.h > +++ b/drivers/net/wireless/realtek/rtw88/tx.h > @@ -7,7 +7,7 @@ > > #define RTK_TX_MAX_AGG_NUM_MASK 0x1f > > -#define RTW_TX_PROBE_TIMEOUT msecs_to_jiffies(500) > +#define RTW_TX_PROBE_TIMEOUT msecs_to_jiffies(2500) > > struct rtw_tx_desc { > __le32 w0;