From nobody Thu Apr 9 09:04:45 2026 Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5E4036C0BB for ; Mon, 9 Mar 2026 21:49:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.160.47 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773092959; cv=pass; b=tYaA+1u1cJOEkMvJWcH5pzCh8pwgecvprnrD9hMOkaBiNy7H8QaVR6QhkybDgfLxr/mRGSiBh3fv3qTOmJoJjbDlHi4xVIJE+Q7cveLEf0sUjnyE2ictM7nDdlJ9wegcJQYdz7H9KQu0qbKK+vry7fWj0nXvOo/no8/zMLMrC5I= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773092959; c=relaxed/simple; bh=snBdrVV45X/SQB505tIEcg2DZ2TcsvSaN5ZbyhoylTU=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=qD88JM6m3pyHpK4pJ+0WZMMHkQ6UqZ0GYncq8uBODRwpnCR3hFh1FP4xBa8Qy1A4cs2geBFAHKCLlpbq/VUGeBtt9ZeL9tVPXtf1DuI699i6sHNLGTnGyk6B42vlbbv+h2SXqCYghBw7MkN1ArL3NHuhzKy7fJaIEkel81qJ+Tc= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=P1pD3V8O; arc=pass smtp.client-ip=209.85.160.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="P1pD3V8O" Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-40423dbe98bso3064447fac.2 for ; Mon, 09 Mar 2026 14:49:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773092957; cv=none; d=google.com; s=arc-20240605; b=YiV/npGACOit8IY3lzGagKbhTOlaMPK4NVyZAl1Qn+ZalQzedjDnzKijcVsgD27l9w H15kjA8JzFaruQpBCyOLPxQVdqDeLI0w8G06tf2Dd44docc9MER38AJHNcnOkhS2h3bn J/FepxhSW74Rx5aAVGcjnzwpa7J6tOCzLRYn9Iaoxcx2uzCGYEOiDeesQ2Cb9rvKOnuu /bkbVVKZv/VZ0Ht4mJxsWJ1aYGZkiiHOgK8ccK9AFhcbJdSlCIhiIrcZlTTq5bH4Atl0 aTZkhNhPD9JiDZAEzkOyO7TB6NxYa2p7dPvPsRhuiYYwqU2i23Dz+3eWLFfBh5QS9dX7 zCGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:mime-version:dkim-signature; bh=snBdrVV45X/SQB505tIEcg2DZ2TcsvSaN5ZbyhoylTU=; fh=Hp+7EbfRUByZqPJZxoeD4tguuFdKGslCHL4p8F4kqOY=; b=WqCIHgY5fU4IvPL9oj8bFqBDKENRG54hdYVZCQnOmBA8vru3rsq5q4BFcr3+z8v9b+ j/IZ+3GDXkV3TR45Nuu5ZrNgyEQwlRUHRtM/1q0g3h/uQVZ2VTGl46u5XG++NCAoSsFi phRt/z9H9Y77v9YLDOGJowvkc6QIEdkKmvL8UmcD3bCnuQFLNEL2VagFAy04BenuvCEI 5hKWJNzeFet3AN4VrRIFol0lDxCbCcDBGL8nvh/jJm3S4V7nfej5vAyWWLnk+TVLJlB5 E3rBTNPjbsJ5lZzIVGJLyY5DUDi24CMg44oV8jVjfN6e0mgvpGzO+ZunAWEdkCMfOisZ YyaA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773092957; x=1773697757; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=snBdrVV45X/SQB505tIEcg2DZ2TcsvSaN5ZbyhoylTU=; b=P1pD3V8OQuckdbb/sv0ZjSrv8YZkfA3ENgt4pfigP1XIHkx3E6vfesLaFri+Y9fijr qj55QMzH/lji0aBqZA4rmtlwaLP2xwFs7C5a93c3ZwGjjZi1hPEo/mCnQu2of9SFq0DD RuGpxIieIEjlvoXRF4pF8nZG2lldh14tXHT7fOIWydcS2jB61sX9rkZzGmhknrc0B9A/ QAWXu0jLiUxRGfZW34N8pGr62DStKMilOriKUlqrZO7oHrIPT+5UI1szgUvEBI3SkhAH 16fKL8WCqjfgpcIB6ga8LGIzLR0KhExXgkxo+MRkfhQ3WczuL+Ihp7MXPuTcalcDtDkR zgIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773092957; x=1773697757; h=cc:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=snBdrVV45X/SQB505tIEcg2DZ2TcsvSaN5ZbyhoylTU=; b=USA94qP81ErIE6Yxr59nLpX5f9Dg7gBcsk2V5FFDwWpAcKKbygAeejHNXJGQGe4S9t sR/pN9n28+zve8n+rV8VYjCwvjmAE7NrpkVT2hwjfoWpgJTrXFF02RlBh0cc6+QyYRsP umpxku854zSAC8B8CW4HGFbxTTJrlSbM4oDFVcF2GLr698k1wUZ7Fwv+EDUlquK92+nu 9T+uQrF8xbgzByOTGEHL+3T+JDt5YjWVmi/ddQx1Wjm0S9kRXsSegtyJ4t7HGaUqrnEZ 979JCaNHRZa20k+BzzYxymXvnYi1rH0v7qDb+VUwh77EB0iMUtzuU7LaiYl2bgha+Vxu C+TQ== X-Forwarded-Encrypted: i=1; AJvYcCV3NqEn4FcL1xRZYwUWIHLXd6FLRuspMgZTIOxue9JxbUc51hiszmZ2XG6aCdDDDiy9SUm6X3AyQ1D2Z8k=@vger.kernel.org X-Gm-Message-State: AOJu0YzKlAhxBY/365qlPVylhjux9wjDc5P/mfI8RRCuL5qozppSTZUg RUGBog3ZrlU19go6PTrYtA13Y8kLx4bgzjdEVpDrc6GDYmXT9XKANhk9rRL0rA5xvTfWNykOR44 doIrNSzWoqYbZxZ5sDCQaBmsjw0hRuCg= X-Gm-Gg: ATEYQzwx3SA2yMVpUQ+qzU5QdKUerbYHMTlkvb8aTx0IUfeY3JNfQw/4pXiB7LugtWT Zkb8bwciMXwvJ0WJR38lR4fjylaSeyrUw4fkbuEAvGV2a35h9DMHtni5BIllIdrdwK4jdbqlNa3 OOcQj5dzFiVpcJmR47hSkPRhnEC7nqvkxAxgiDmsRJa9YAguYb43ZbZoT4xzEN9GAeA2TkB/NwO m/JCebgemGsOELsJa0l7mhKJqQfsEZpSykygEcRcNQqWKHN7fecCER9MPNO6BVfxRFGdCMuXhmE iGRzrYHaS7OgZGrtu+1CLTo+wbqx+7nweOA= X-Received: by 2002:a05:6871:2894:b0:40e:dadc:4a05 with SMTP id 586e51a60fabf-416e3e8495cmr7542519fac.8.1773092956735; Mon, 09 Mar 2026 14:49:16 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: LB F Date: Mon, 9 Mar 2026 23:48:40 +0200 X-Gm-Features: AaiRm53ODi1ilOkfswM2O1JJXvOtIRlUAH6PUKNLP6FARCooUHedTa_7UF-6n4Q Message-ID: Subject: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict) To: pkshih@realtek.com Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Ping-Ke, I am writing to formally report a critical bug that causes a hard system freeze on laptops equipped with the RTL8821CE WiFi module, and to propose solutions. Description: On an HP laptop equipped with a Realtek RTL8821CE 802.11ac PCIe adapter (PCI ID: 10ec:c821), the system experiences a hard lockup (complete freeze of the UI and kernel, sysrq doesn't work, requires holding the power button) when the WiFi adapter enters the power saving state. This issue occurs consistently across multiple Linux distributions and kernel versions (reproduced on upstream kernel 6.13 and 6.19-rc). Steps to Reproduce: 1. Use a system with RTL8821CE (pci:10ec:c821). 2. Ensure NetworkManager is configured with wifi.powersave =3D 3 (or power saving is enabled via TLP/iw). 3. Connect to a WiFi network and let the system idle. 4. The system will eventually freeze completely. Workarounds that successfully prevent the freeze: * Passing disable_lps_deep=3Dy to rtw88_core. * Passing disable_aspm=3Dy to rtw88_pci (or pcie_aspm=3Doff). * Disabling WiFi power save via NetworkManager. Technical Analysis: The root cause appears to be an unhandled race condition or hardware bug between the adapter's Low Power State (LPS) Deep mode (LPS_DEEP_MODE_LCLK) and the PCIe Active State Power Management (ASPM L1) mechanism. When the firmware drops into LPS_DEEP_MODE_LCLK concurrently with the PCIe bus entering ASPM L1, the chip fails to handle PCIe Wake signaling correctly. While there is an existing workaround in rtw_pci_napi_poll (pci.c:1806) that sets `rtwpci->rx_no_aspm =3D true` during NAPI poll for 8821CE, this polling wrapper is insufficient. The deadlock often occurs during idle states when polling isn't actively disabling ASPM, but the system suddenly needs to wake the radio. Proposed Solutions: Given that LPS_DEEP_MODE_LCLK seems fundamentally unreliable on 8821ce PCIe variants when paired with standard Windows-era ASPM implementations on laptops (HP, Lenovo, ASUS are all affected), the most robust solution is to strip the unsupported deep sleep flag from the hardware spec. ```diff Tested-by: Oleksandr Havrylov --- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c +++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c @@ -1999,7 +1999,7 @@ struct rtw_chip_info rtw8821c_hw_spec =3D { .bt_supported =3D true, .fbtc_has_ext_ctrl =3D true, .coex_info_hw_supported =3D true, - .lps_deep_mode_supported =3D BIT(LPS_DEEP_MODE_LCLK), + .lps_deep_mode_supported =3D 0, /* Disabled due to ASPM L1 hard locks */ .dpk_supported =3D true, .pstdma_type =3D COEX_PSTDMA_FORCE_LPSOFF, .bfee_support =3D false, ``` Alternatively, a PCI Subsystem-based quirk should be introduced in rtw_pci_aspm_set() to refuse ASPM BIT_L1_SW_EN transitions for affected hardware IDs, similar to how CLKREQ issues are handled for 8822C via efuse->rfe_option. Cross-Reference Analysis of other RTL8821CE Bugs: After aggregating recent open bug reports for the 8821ce chip on Bugzilla (https://bugzilla.kernel.org), it is apparent that almost all of them are victims of the exact same underlying race condition. 1. Bug 215131: System freeze preceded by 'pci bus timeout, check dma status'. Workaround used: disable_aspm=3D1. 2. Bug 219830: Log shows 'firmware failed to leave lps state' and 'failed to send h2c command'. A direct smoking gun for LPS Deep mode freezing. 3. Bug 218697 & Bug 217491: Endless 'timed out to flush queue' floods. 4. Bug 217781 & Bug 216685: Random dropouts and low wireless speed. Given the volume and age of these unresolved reports, disabling .lps_deep_mode_supported (or restricting ASPM L1) specifically for 10ec:c821 is desperately needed. System Information: - Hardware: HP Notebook (SKU: P3S95EA#ACB, Family: 103C_5335KV) - CPU: Intel Core i3-5005U - WiFi PCI ID: 10ec:c821, Subsystem: 103c:831a - Kernel: 6.13 / 6.19 - Driver module: rtw88_8821ce I am happy to test any patches provided or formally submit the patch above if maintainers agree it is the right approach. Thank you!