You are not logged in.

#1 2022-12-12 03:56:30

cstn
Member
Registered: 2019-12-24
Posts: 37

[DISCUSS] RTL8821CE, D3cold to D0 Unable Change, Weird Issue.

I got a weird issue for this rtl8821ce network controller card. I have solved this to work again. Just write the things here to help someone if they need this. Or discuss this issue if you want say something.

rtl8821ce is a internal pcie network controller card.

I have a laptop with intel Gemini Lake cpu J4125 with rtl8821ce. Wifi works well.
Then I get a newer laptop with intel Jasper Lake cpu Celeron N5100, with rtl8821ce also.
I backup and restore my Archlinux from old laptop to the new one. Boot system up but found the wifi didn't work.

# dmesg | grep 8821
[    4.032295] Bluetooth: hci0: RTL: examining hci_ver=08 hci_rev=000c lmp_ver=08 lmp_subver=8821
[    4.033300] Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_fw.bin
[    4.039035] Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_config.bin
[    5.801646] rtw_8821ce 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible
[    5.806499] rtw_8821ce 0000:01:00.0: mac power on failed
[    5.806504] rtw_8821ce 0000:01:00.0: failed to power on mac
[    5.806506] rtw_8821ce 0000:01:00.0: failed to setup chip efuse info
[    5.806507] rtw_8821ce 0000:01:00.0: failed to setup chip information
[    5.823963] rtw_8821ce 0000:01:00.0: Firmware version 24.11.0, H2C version 12
[    5.846277] rtw_8821ce: probe of 0000:01:00.0 failed with error -114
[    7.949832] rtl8821ce 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible

I also found a failure log from dmesg, this acpi0003:01 may be a microsoft ac power device, I don't know what it exactly is.

# dmesg | grep fail
[    0.478774] ac: probe of ACPI0003:01 failed with error -17

There is 3 kernels in my system, tested and found this:
linux-rt-bfq-dev 5.18.rt11-17 (wifi works, though there's some fail/error 'tx' warnings in dmesg)
linux-rt 6.0.5.14.realtime1-2 (wifi not work, Unable to change power state from D3cold to D0)
linux 6.0.11-arch1-1 (wifi not work, Unable to change power state from D3cold to D0)

For some reason, I modified my /etc/fstab, and accidentally made the SWAP partition UUID wrong. then reboot system, the boot time cost more than about 90 seconds (in normal case, it boot up just very few seconds), because system stuck at the wrong SWAP partition UUID when boot up. But with the long time boot up, I found the wifi works again, 3 different kernels all works. But this is not the final solution, no one want a long time boot.

When I search "D3cold to D0" from internet, found these threads:
https://forum.manjaro.org/t/nvidia-cant … ible/31979
https://forums.developer.nvidia.com/t/b … /112912/15

They mentioned:
"...PCI PM state changes doesn't seem to occur instantly after it is requested meaning a state change from D0 -> D3cold or vice versa may take a few seconds. During that time, any state changes requested will result to 'can't change power state from D3cold to D0' ...'"

It seems they get same issue with mine, the wrong pcie device Power Management when system boot up.

I got some suggestions from these two driver README pages:
https://github.com/tomaspinho/rtl8821ce
https://github.com/lwfinger/rtw88

Finally, My solution is use tlp.conf to control the rtl8821ce pcie pm:
edit/modify the /etc/tlp.conf,

#set pcie runtime pm to 'auto'
RUNTIME_PM_ON_AC=auto
RUNTIME_PM_ON_BAT=auto

# add rtl8821ce pcie address to deny the runtime pm 'auto' configuration
RUNTIME_PM_DENYLIST="01:00.0"

then, reboot system, the wifi works again instantly. check the command, the trl8821ce is powered on, not 'auto' :

# tlp-stat --pcie
...
+++ PCIe Runtime Power Management
Enable devices    = (disabled)
Disable devices   = (disabled)
Device denylist   = 01:00.0
Driver denylist   = mei_me nouveau radeon
...
/sys/bus/pci/devices/0000:01:00.0/power/control = on   (0x028000, Network controller, rtw_8821ce)

At last, I have two questions:
1. Is this issue caused by different BIOS firmware?
2. Because the kernel 5.18 wifi works before I found the solution, so, if it's not about BIOS firmware, then is it a bug from linux kernel 6.0 and newer versions ?

Last edited by cstn (2022-12-12 04:30:33)

Offline

Board footer

Powered by FluxBB