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: 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 [this message]
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
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 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.