From: Ping-Ke Shih <pkshih@realtek.com>
To: Abdurrahman Karadag <abdurrahmankaradag19@gmail.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: RE: [BUG] rtw88 8821ce: connection wedges (100% loss until reboot) with station power save
Date: Fri, 28 Aug 2026 03:48:28 +0000 [thread overview]
Message-ID: <8ca74ba7d3164357ab644f2ddd456758@realtek.com> (raw)
In-Reply-To: <20260826162514.80580-1-abdurrahmankaradag19@gmail.com>
Abdurrahman Karadag <abdurrahmankaradag19@gmail.com> wrote:
> Hardware:
> RTL8821CE [10ec:c821], subsystem AzureWave [1a3b:304a]
> PCIe root port Intel [8086:51be] (00:1c.6)
> ASUS Vivobook X1504ZA, firmware rtw8821c_fw.bin 24.11.0
> (feature word 0x7: SIG|LPS_C2H|LCLK, no TX_WAKE)
> Arch Linux, kernel 7.1.9 (also seen on 7.0.12).
Is there are version it works well on your platform?
I'm thinking bisect is a method to find cause.
>
> Symptom:
> At some unpredictable point the connection wedges: traffic goes to 100%
> packet loss and STAYS there until a reboot. The interface still shows as
> associated (iwd/networkd report it connected, DHCP lease held), but nothing
> passes - gateway ARP goes INCOMPLETE and stays that way. It does not
> gradually degrade or self-heal; it is a hard stop that only a reboot clears.
> It tends to hit soon after boot / when joining a network rather than on a
> connection that has already been up for a long time.
I'd reply this by the latter mail of yours.
>
> The one reliable workaround is disabling station power save:
> iw dev wlan0 set power_save off
> With power save off I have not hit the wedge; with it on it recurs. This is
> the strongest signal I have that the station-PS path is involved.
(Asked to disregard this.)
>
> What I ruled out (each tested on this machine):
> - rtw88_pci disable_aspm=y : no effect (the module param only gates the
> device DBI 0x719 bit; it does not call
> pci_disable_link_state, so host ASPM
> L1/L1ss stay on - link/l1* remain 1)
> - rtw88_core disable_lps_deep=y : no effect (firmware deep-PS off)
The full cold power-off boot includes above two settings, right?
> - full cold power-off boot : no effect
> - suspend/resume : NOT the trigger - connectivity recovers
> fine after resume in my tests
> - The correctable PCIe "Physical Layer / RxErr" this card logs is DECOUPLED
> from the failure: I measured the link working perfectly both while RxErr is
> being logged and while it is absent. RxErr is not the cause.
How did you measure the link? CAT-C?
>
> Reproduction (honest):
> I could not reproduce the wedge deterministically. Controlled tests all
> passed on the stock driver: steady-state idle (minutes), long idle with an
> off-device pinger sending to the sleeping STA, and disconnect/reconnect
> loops. So it is intermittent and tied to station PS being active, but I have
> not found the exact trigger - which is why the reliable handle is
> "power_save off makes it stop".
>
> Questions:
> - Is a hard wedge (RX/TX stops until reboot) with station power save a known
> failure mode on 8821ce? Does the driver have any watchdog/recovery for a
> firmware or RX-DMA stall on this chip, or does it rely on the firmware?
The latter mail of yours explain RX is fully intact.
For RX path, if beacon gets loss, it will disconnect, so I think RX still works
for your case.
> - rtw_enter_lps_core() (ps.c) programs the same PS config for every chip
> (rlbm=1, smart_ps=2, awake_interval=1) with no chip-specific override.
> Given fw feature word 0x7 (no TX_WAKE) on 8821ce, could smart-PS mode 2
> be the problem, and would legacy PS-Poll (smart_ps=0) for
> RTW_CHIP_TYPE_8821C be worth trying?
It looks like it still happened if you entirely turn off power save, so
ignore this...
prev parent reply other threads:[~2026-08-28 3:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 16:25 [BUG] rtw88 8821ce: connection wedges (100% loss until reboot) with station power save Abdurrahman Karadag
2026-08-26 18:00 ` Abdurrahman Karadag
2026-08-28 3:57 ` Ping-Ke Shih
2026-08-28 3:37 ` Abdurrahman Karadag
2026-08-28 3:48 ` 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=8ca74ba7d3164357ab644f2ddd456758@realtek.com \
--to=pkshih@realtek.com \
--cc=abdurrahmankaradag19@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).