From: Ping-Ke Shih <pkshih@realtek.com>
To: "Jeffrey Wälti" <jeffrey@waelti.dev>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: RE: wifi: rtw89: rtw8922ae: HWSI bus lockup during RF recalibration on AP bandwidth change
Date: Tue, 7 Apr 2026 00:38:13 +0000 [thread overview]
Message-ID: <b53454830dfc4e2e9d43aa8689fd8f99@realtek.com> (raw)
In-Reply-To: <dFJeMTbWtJdpQXoZpQRv85Z8BumU9LW5xY5D4Hnuri6Zez_Gkk8XL6zNEuCFN1djAEqsTA9-mJb1ygNXX-V72HL4Q3Vit_1JY1-xBHBm5SQ=@waelti.dev>
Jeffrey Wälti <jeffrey@waelti.dev> wrote:
>
> Jeffrey Wälti <jeffrey@waelti.dev> wrote:
>
> > Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > > Jeffrey Wälti <jeffrey@waelti.dev> wrote:
> > > >
> > > > Ping-Ke Shih <pkshih@realtek.com> wrote:
> > > >
> > > > > Jeffrey Wälti <jeffrey@waelti.dev> wrote:
> > > > > >
> > > > > > <pkshih@realtek.com> wrote:
> > > > > >
> > > > > > >
> > > > > > > Please try to disable power save and ASPM by
> > > > > > > 1) iw wlan0 set power_save off
> > > >
> > > > I'm sorry, this is my first time interacting with the mailing list and I overlooked the other
> instructions.
> > > > It seems like disabling power save gets rid of the issue of Wi-Fi timeouts. I haven't been able
> to
> > > > reproduce the issue with `iw wlan0 set power_save off` yet, even without any of the other fixes
> on kernel
> > > > 6.19.10 and 7.0-rc6.
> > > >
> > > > > > > 2) reference and install
> > > > > > https://github.com/lwfinger/rtw89/blob/main/70-rtw89.conf
> > > > > > > and then cold reboot.
> > > > >
> > > > > Have you tested with these conditions?
> > > >
> > > > Using this patch eliminates the issue of Bluetooth devices disconnecting, when switching between
> > > > networks.
> > > >
> > > > > [...]
> > > > >
> > > > > > >
> > > > > > > Please help to test the latest kernel 7.0-rc with additional patch [1].
> > > > > > >
> > > > > > > [1]
> > > > > > https://lore.kernel.org/linux-wireless/20260310080146.31113-4-pkshih@realtek
> > > > > > .com/
> > > > >
> > > > > Have you also applied this patch?
> > > >
> > > > I tested kernel 7.0-rc6 with this patch applied on top for ~1 day now and haven't been able to
> reproduce,
> > > > even with power save enabled. However, it is a bit difficult to reliably trigger the issue as
> it seems
> > > > to trigger more on certain networks than others etc.
> > > >
> > > > > > >
> > > > > > > Ping-Ke
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Thank you for coming back to me so quickly, I just encountered the same thing
> > > > > > with kernel 7.0-rc5.
> > > > > >
> > > > >
> > > > > Please confirm my questions above.
> > > > >
> > > > > Ping-Ke
> > > > >
> > > > >
> > > >
> > > > In summary:
> > > > - Disabling power save seems to stop the timeouts but Bluetooth issues remain
> > > > - Disabling ASPM features fixes the Bluetooth issue
> > > > - kernel 7.0-rc6 with the additional patch fixes Wi-Fi timeouts but not the Bluetooth disconnects
> > > >
> > > > I hope that answers your questions.
> > >
> > > It looks like additional patch can fix the WiFi timeouts problem, and
> > > disabling ASPM feature can fix Bluetooth issue. I think you can keep
> > > (2) + (3) setting as workaround.
> > >
> > > I'd talk with BT coexistence team internally to figure out the cause
> > > of Bluetooth disconnection.
> >
> > As always, thank you very much for coming back to me so quickly and working on a fix. Please do let
> me know if there is any progress on the issue or if you need any more help testing a patch.
>
> Hi again,
>
> I'm sorry for coming back to you so quickly once again, but I am sad to report, that I just encountered
> the same issue again with kernel 7.0-rc6 and the custom patch applied.
What did custom patch you mentioned? The additional patch I mentioned?
> After resume the Wi-Fi connection
> ran at less than 1/100 of the expected speed and wouldn't come back up, until I reconnected to the same
> network. It seems like just the custom patch was not enough to fix the underlying issue, but it did
> fix the HWSI lock up. This is what dmesg tells me.
>
> [126462.035430] PM: suspend exit
> [126465.615935] wlan0: authenticate with 68:67:c7:2a:20:43 (local address=7c:fa:80:c3:5b:f9)
> [126465.615944] wlan0: send auth to 68:67:c7:2a:20:43 (try 1/3)
> [126465.634818] wlan0: send auth to 68:67:c7:2a:20:43 (try 2/3)
> [126465.654072] wlan0: send auth to 68:67:c7:2a:20:43 (try 3/3)
> [126465.673115] wlan0: authentication with 68:67:c7:2a:20:43 timed out
This said that it failed to TX auth or RX auth. I suggest to disable
Bluetooth entirely to see it can improve.
> [126466.065780] wlan0: authenticate with 68:67:c7:2a:20:42 (local address=7c:fa:80:c3:5b:f9)
> [126466.065789] wlan0: send auth to 68:67:c7:2a:20:42 (try 1/3)
> [126468.082718] wlan0: send auth to 68:67:c7:2a:20:42 (try 2/3)
> [126470.107802] wlan0: send auth to 68:67:c7:2a:20:42 (try 3/3)
> [126471.070743] wlan0: aborting authentication with 68:67:c7:2a:20:42 by local choice (Reason:
> 3=DEAUTH_LEAVING)
> [126474.858695] wlan0: authenticate with 68:67:c7:2a:20:43 (local address=7c:fa:80:c3:5b:f9)
> [126474.858705] wlan0: send auth to 68:67:c7:2a:20:43 (try 1/3)
> [126474.879430] wlan0: authenticate with 68:67:c7:2a:20:43 (local address=7c:fa:80:c3:5b:f9)
> [126474.879439] wlan0: send auth to 68:67:c7:2a:20:43 (try 1/3)
> [126474.884633] wlan0: authenticated
> [126474.885578] wlan0: associate with 68:67:c7:2a:20:43 (try 1/3)
> [126474.899521] wlan0: RX AssocResp from 68:67:c7:2a:20:43 (capab=0x1011 status=0 aid=20)
> [126475.002744] wlan0: associated
> [126475.002799] wlan0: Limiting TX power to 23 (23 - 0) dBm as advertised by 68:67:c7:2a:20:43
> [126490.802365] ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast] and [Long_Life] are
> enabled
> [126627.760736] ideapad_acpi VPC2004:00: unexpected charge_types: both [Fast] and [Long_Life] are
> enabled
>
> (Here I decide to manually reconnect to the same network)
>
> [126737.556015] wlan0: deauthenticating from 68:67:c7:2a:20:43 by local choice (Reason:
> 3=DEAUTH_LEAVING)
> [126738.215678] wlan0: authenticate with 68:67:c7:2a:20:43 (local address=7c:fa:80:c3:5b:f9)
> [126738.215697] wlan0: send auth to 68:67:c7:2a:20:43 (try 1/3)
> [126740.272244] wlan0: send auth to 68:67:c7:2a:20:43 (try 2/3)
> [126740.291264] wlan0: authenticate with 68:67:c7:2a:20:43 (local address=7c:fa:80:c3:5b:f9)
> [126740.291271] wlan0: send auth to 68:67:c7:2a:20:43 (try 1/3)
> [126740.293310] wlan0: authenticated
> [126740.294214] wlan0: associate with 68:67:c7:2a:20:43 (try 1/3)
> [126740.303679] wlan0: RX AssocResp from 68:67:c7:2a:20:43 (capab=0x1011 status=0 aid=21)
> [126740.409430] wlan0: associated
> [126740.409517] wlan0: Limiting TX power to 23 (23 - 0) dBm as advertised by 68:67:c7:2a:20:43
>
> I will resume testing with the power save function turned off, to check if that still is a working
> workaround for now.
Please test it.
Ping-Ke
prev parent reply other threads:[~2026-04-07 0:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 10:58 wifi: rtw89: rtw8922ae: HWSI bus lockup during RF recalibration on AP bandwidth change Jeffrey Wälti
2026-03-24 2:02 ` Ping-Ke Shih
2026-03-25 19:25 ` Jeffrey Wälti
2026-03-26 0:23 ` Ping-Ke Shih
2026-04-01 11:24 ` Jeffrey Wälti
2026-04-02 2:36 ` Ping-Ke Shih
[not found] ` <nPBjkph3lQo2eiuYIDyn7Mx8rg_pYRHNkQ-yyIVecS7isXyz4KC77Kud29sqnGKgCVgZS_IM1Jj28gx1RN4iaLuyKhS_MZVUnXhy-BVGCfQ=@waelti.dev>
2026-04-03 10:43 ` Jeffrey Wälti
2026-04-07 0:38 ` Ping-Ke Shih [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b53454830dfc4e2e9d43aa8689fd8f99@realtek.com \
--to=pkshih@realtek.com \
--cc=jeffrey@waelti.dev \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.