From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
To: LB F <goainwo@gmail.com>, Ping-Ke Shih <pkshih@realtek.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: Fri, 27 Mar 2026 12:52:45 +0200 [thread overview]
Message-ID: <da30a61b-dad0-48ff-a283-3dd8e9bdf91d@gmail.com> (raw)
In-Reply-To: <CALdGYqQ_RCOwa2J-GsEyCxCQ4bztyxSzbc+6eYNesBSaY3Nt-w@mail.gmail.com>
On 27/03/2026 01:52, LB F wrote:
> Hi Ping-Ke,
>
> This is Oleksandr Havrylov again. Thank you for the ASPM/LPS Deep
> quirk and the rate validation patches — they are both working correctly
> (zero h2c timeouts, zero lps failures, zero mac80211 warnings).
>
> However, I'm experiencing a different, separate bug that causes kernel
> oops and makes the system completely unresponsive, requiring a hard
> power-off. After disassembling the crash site, I believe I've found
> the root cause.
>
> == Summary ==
>
> When firmware sends a C2H_ADAPTIVITY (0x37) command to an RTL8821CE
> adapter, rtw_fw_adaptivity_result() dereferences rtwdev->chip->edcca_th
> without a NULL check. The RTL8821C chip_info (rtw8821c_hw_spec) does
> not define edcca_th, so the pointer is NULL, causing a kernel oops.
>
> The crash occurs on the phy0 workqueue while holding rtwdev->mutex,
> which never gets released. This causes all subsequent processes that
> touch the network stack to hang in uninterruptible D-state, making
> the system completely unresponsive and requiring a hard power-off.
>
> == Root cause analysis ==
>
> rtw_fw_adaptivity_result() in fw.c (line ~282):
>
> static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
> u8 length)
> {
> const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
> ...
> rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY, "Reg Setting: L2H %x H2L %x\n",
> rtw_read32_mask(rtwdev, edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
> ^^^^^^^^^ NULL dereference here
> edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask),
> ...
>
> The RTL8822C defines .edcca_th = rtw8822c_edcca_th in its chip_info,
> but RTL8821C does not set this field at all — it remains NULL.
>
> I verified this by disassembling the compiled rtw_core.ko module:
>
> Crash RIP: rtw_fw_c2h_cmd_handle+0x127
> Address: 0x1d527 = movl (%r12), %esi
>
> R12 is loaded at +0xe5 (0x1d4e5):
> movq 0x140(%rax), %r12 ; rax = rtwdev->chip
> ; 0x140 = offset of edcca_th in rtw_chip_info
> ; R12 = chip->edcca_th = NULL for 8821c
>
> The function is entered via:
> +0xd8 (0x1d4d8): cmpl $0x37, %ecx ; c2h->id == C2H_ADAPTIVITY (0x37)
>
> With R12 = 0, the instruction at +0x127:
> movl (%r12), %esi ; reads from address 0x0 → NULL pointer dereference
>
> I also confirmed that rtw8821c_hw_spec in the mainline kernel
> (torvalds/linux master, rtw8821c.c) does NOT set .edcca_th.
>
> == Reproduction ==
>
> The crash is highly reproducible: it occurred in 4 out of 7 recent
> boots. It happens during normal active usage with no specific trigger.
>
> boot date/time of crash uptime at crash
> -5 2026-03-25 00:58:06 ~2 min
> -4 2026-03-25 21:32:00 ~6h
> -3 2026-03-26 00:28:14 ~2.5h
> -1 2026-03-27 00:56:58 ~23.5h
>
> Both ASPM and LPS Deep are disabled via the DMI quirk. The crash
> occurs every time with the same pattern and same RIP offset (+0x127).
>
> == Crash pattern ==
>
> Every crash follows the same sequence:
>
> 1) Burst of 50-60 "unused phy status page" messages in ~1 second:
>
> rtw_8821ce 0000:13:00.0: unused phy status page (8)
> rtw_8821ce 0000:13:00.0: unused phy status page (2)
> ... (50+ more within same second)
>
It looks like the firmware is not sending C2H_ADAPTIVITY (unexpected
for RTL8821CE), but rather you are getting garbage RX data. I am
curious what kind of garbage it is. Can you try this?
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821c.c b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
index da67a6845fd5..aae246c2bc8e 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
@@ -665,6 +665,7 @@ static void query_phy_status(struct rtw_dev *rtwdev, u8 *phy_status,
struct rtw_rx_pkt_stat *pkt_stat)
{
u8 page;
+ u8 *rxdesc = phy_status - rtwdev->chip->rx_pkt_desc_sz - pkt_stat->shift;
page = *phy_status & 0xf;
@@ -677,6 +678,10 @@ static void query_phy_status(struct rtw_dev *rtwdev, u8 *phy_status,
break;
default:
rtw_warn(rtwdev, "unused phy status page (%d)\n", page);
+ print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 4, 4,
+ rxdesc, 56, true);
+ print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1,
+ rxdesc, 40, true);
return;
}
}
next prev parent reply other threads:[~2026-03-27 10:52 UTC|newest]
Thread overview: 36+ 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 [this message]
2026-03-16 2:50 ` Ping-Ke Shih
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=da30a61b-dad0-48ff-a283-3dd8e9bdf91d@gmail.com \
--to=rtl8821cerfe2@gmail.com \
--cc=goainwo@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=pkshih@realtek.com \
/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