From: Ping-Ke Shih <pkshih@realtek.com>
To: LB F <goainwo@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
Date: Mon, 16 Mar 2026 02:50:15 +0000 [thread overview]
Message-ID: <74569e958a5d4f3b9c857c1ecc8ec274@realtek.com> (raw)
In-Reply-To: <CALdGYqSq416qqqZ7t+wG5fir9NWfi3578+brdaj05q-42Gj14w@mail.gmail.com>
LB F <goainwo@gmail.com> wrote:
> Ping-Ke Shih <pkshih@realtek.com> wrote:
> > I'd adopt your suggestion (dynamic LPS_DEEP_MODE_NONE) if the test
> > is positive.
>
> Hi Ping-Ke,
>
> Following your suggestion, I performed an additional experiment to
> validate the dynamic LPS_DEEP_MODE_NONE idea. Please treat this
> purely as a field test report -- I am not a kernel developer, and the
> implementation below is certainly not upstream-quality. I am sharing
> it only in the hope that it helps you design a proper solution.
>
> What I did:
>
> I extended your DMI quirk in pci.c with an additional capability flag
> for LPS Deep mode. The only file touched was pci.c (your patch) --
> main.c was left completely unmodified.
>
> The changes to your patch are as follows:
>
> /* 1. Extended the capabilities enum */
> enum rtw88_quirk_dis_pci_caps {
> QUIRK_DIS_PCI_CAP_ASPM,
> QUIRK_DIS_PCI_CAP_LPS_DEEP, /* test addition */
> };
>
> /* 2. Extended disable_pci_caps() callback */
> static int disable_pci_caps(const struct dmi_system_id *dmi)
> {
> uintptr_t dis_caps = (uintptr_t)dmi->driver_data;
>
> if (dis_caps & BIT(QUIRK_DIS_PCI_CAP_ASPM))
> rtw_pci_disable_aspm = true;
>
> if (dis_caps & BIT(QUIRK_DIS_PCI_CAP_LPS_DEEP))
> rtw_disable_lps_deep_mode = true;
>
> return 1;
> }
>
> /* 3. Both flags set for the HP P3S95EA#ACB entry */
> .driver_data = (void *)(BIT(QUIRK_DIS_PCI_CAP_ASPM) |
> BIT(QUIRK_DIS_PCI_CAP_LPS_DEEP)),
>
> I am aware that setting rtw_disable_lps_deep_mode from pci.c is
> architecturally impure -- it is a global flag that would affect all
> rtw88 devices in a hypothetical multi-adapter system. A proper
> per-device solution (e.g. a flag inside struct rtw_dev set during
> probe) would be cleaner. I simply used the existing global as the
> most straightforward way to validate the concept.
>
> Verification:
>
> Confirmed no rtw88-related entries exist in /etc/modprobe.d/,
> /lib/modprobe.d/, or /run/modprobe.d/, ruling out any external
> parameter injection.
>
> After loading the patched modules, the following was confirmed via
> sysfs:
>
> /sys/module/rtw88_core/parameters/disable_lps_deep_mode = Y
> /sys/module/rtw88_pci/parameters/disable_aspm = Y
>
> This confirms the DMI quirk is the sole source of both values.
>
> Results (10-minute idle observation, battery power, wifi.powersave=3):
>
> With your ASPM patch alone (LPS Deep still active):
> - periodic "failed to send h2c command" bursts observed
> - occasional WiFi throughput drops and Bluetooth audio stuttering
>
> With ASPM patch + LPS Deep disabled via the quirk:
> - h2c=0, lps=0 across the entire observation window
> - WiFi throughput stable, Bluetooth audio uninterrupted
>
> The result confirms that disabling LPS Deep Mode in addition to ASPM
> completely eliminates the remaining firmware timeout loop on this
> platform.
>
> I hope this experiment is useful as a data point. Please feel free to
> discard the implementation and design a proper solution -- I am ready
> to test any updated patch you send.
Thanks for your analysis of TX/RX paths, and the changes above and
verifications. :)
I'd update the patch as your proposal and send a patch. For suggestions of
TX/RX paths, I only read them a little bit, and I will study them entirely
when I have more free time.
Ping-Ke
prev parent reply other threads:[~2026-03-16 2:50 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 21:48 [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict) LB F
2026-03-10 2:02 ` Ping-Ke Shih
2026-03-10 11:01 ` LB F
2026-03-10 15:12 ` LB F
2026-03-11 2:20 ` Ping-Ke Shih
2026-03-11 2:15 ` Ping-Ke Shih
2026-03-11 2:22 ` Ping-Ke Shih
2026-03-11 11:00 ` LB F
2026-03-11 15:22 ` LB F
2026-03-12 1:56 ` Ping-Ke Shih
2026-03-12 21:42 ` LB F
2026-03-13 0:03 ` LB F
2026-03-13 0:29 ` LB F
2026-03-14 10:52 ` LB F
2026-03-14 12:39 ` LB F
2026-03-15 0:24 ` LB F
2026-03-16 2:55 ` Ping-Ke Shih
2026-03-16 20:27 ` LB F
2026-03-17 1:28 ` Ping-Ke Shih
2026-03-18 0:00 ` LB F
2026-03-18 0:58 ` Ping-Ke Shih
2026-03-18 23:55 ` LB F
2026-03-19 0:22 ` LB F
2026-03-19 0:49 ` Ping-Ke Shih
2026-03-19 1:24 ` Ping-Ke Shih
2026-03-19 23:58 ` LB F
2026-03-20 0:41 ` LB F
2026-03-20 1:00 ` Ping-Ke Shih
2026-03-20 1:19 ` LB F
2026-03-20 2:02 ` Ping-Ke Shih
2026-03-21 12:07 ` LB F
2026-03-23 2:01 ` Ping-Ke Shih
2026-03-25 20:38 ` LB F
2026-03-26 23:52 ` LB F
2026-03-27 10:52 ` Bitterblue Smith
2026-03-28 11:41 ` LB F
2026-03-28 13:07 ` Bitterblue Smith
2026-03-28 13:40 ` LB F
2026-03-28 18:52 ` Bitterblue Smith
2026-03-28 20:59 ` LB F
2026-03-28 21:31 ` LB F
2026-03-28 21:53 ` LB F
2026-03-30 1:23 ` Ping-Ke Shih
2026-03-30 11:34 ` LB F
2026-03-31 0:32 ` Ping-Ke Shih
2026-04-03 21:47 ` LB F
2026-04-04 10:44 ` LB F
2026-04-06 12:41 ` LB F
2026-04-08 14:26 ` Bitterblue Smith
2026-04-26 20:38 ` Bitterblue Smith
2026-04-26 23:17 ` LB F
2026-04-27 0:26 ` LB F
2026-04-27 10:08 ` LB F
2026-04-27 21:19 ` LB F
2026-04-27 21:30 ` Bitterblue Smith
2026-04-27 21:48 ` LB F
2026-04-27 22:25 ` LB F
2026-04-29 20:13 ` LB F
2026-04-30 10:56 ` LB F
2026-03-16 2:50 ` 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=74569e958a5d4f3b9c857c1ecc8ec274@realtek.com \
--to=pkshih@realtek.com \
--cc=goainwo@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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.