Bug 206411

Also have this problem with the same error logs of "mac power on failed" and "failed to power on mac". The problem sometimes disappears after a restart to Windows and restart back to Linux.

I'm facing a similar issue; the rtwpci driver is constantly using 10-20% of CPU and as such my HP Envy x360 13-ag0011nv is thermal throttling. I'm running 5.4.26-1-lts kernel on Arch Linux. I'm having this issue with all kernels, to the latest version in Arch repos.

I'm also getting this problem on Fedora 31 with kernel 5.5, more specifically kernel-core-5.5.13-200.fc31.

This problem seems to have been introduced with this commit:
https://github.com/torvalds/linux/commit/d2e2c47e65af7310ad7d40ebf4cbb1d898719ec2
in the 5.5 kernel, but my 'c' coding skills are pretty limited, so may be something else closely related.

I have no trouble with this driver in the 5.4 kernel.

Why was working driver replaced by this if those who did it are not going to try and get it working.

How can I go back to the old driver which actually works? Very frustrating.

Hey, the patch enables PCI CLKREQ to reduce power consumption under power save state. But it seems like that mech has some inter-op issues with some platform.

Maybe we should add a module parameter or something to disable it after the driver is built. But as far as I know, the maintainers aren't going to like the module parameters, it makes the maintainence more difficult (they need to take care of them in configurations files or something). So, if there is a better way to do it please give me a hint. Or if there're too many people suffering from it, I can try to use the evil module parameter again, but it's when there's no other way we can go.

Unfortunately, if you want to get the code working, you can just modify the code manually. Either revert the patch or return upon the CLKREQ functions will do. For example:


diff --git a/pci.c b/pci.c
index 9f5edb8e..d9469ebf 100644
--- a/pci.c
+++ b/pci.c
@@ -1199,6 +1199,8 @@ static void rtw_pci_clkreq_set(struct rtw_dev *rtwdev, bool enable)
        u8 value;
        int ret;

+       return;
+
        ret = rtw_dbi_read8(rtwdev, RTK_PCIE_LINK_CFG, &value);
        if (ret) {
                rtw_err(rtwdev, "failed to read CLKREQ_L1, ret=%d", ret);
@@ -1218,6 +1220,8 @@ static void rtw_pci_aspm_set(struct rtw_dev *rtwdev, bool enable)
        u8 value;
        int ret;

+       return;
+
        ret = rtw_dbi_read8(rtwdev, RTK_PCIE_LINK_CFG, &value);
        if (ret) {
                rtw_err(rtwdev, "failed to read ASPM, ret=%d", ret);

Tested the patch on Comment 5 on 5.6.10 and it works. Thanks, Yen-Hsuan!


Notice that you may need to restore the wireless hardware to "a normal state" (say, it can be used by linux <5.5. A simple approach is to connect to a wireless network via Windows.) before using the patched rtw88 module.

Hi Yen-Hsuan,

Thanks for looking into this. I would be happy to test a patched kernel, but I'm afraid patching and building kernels is a bit beyond my skill set and abilities.

Created attachment 289515 [details]
A shell helps building and installing the patched version of rtw88 on Arch Linux

Hi Trevor,

I've uploaded a shell script, modified from the PKGBUILD of Arch Linux's linux package, tested on Arch Linux, which might be helpful for you as a reference.


Hi Yen-Hsuan,

I've tested this patch and find it seems to be not always working. What I did was:

1. Boot from Windows and connect to the Internet
2. Boot again from patched 5.6.10, it works
3. Boot again from 5.4.43 (LTS, which doesn't have this problem), it works
4. Boot again from patched 5.6.10, it doesn't work

Some platforms don't disconnect to the power when "shutdown", and if so, the power sequence may be different. If you manually remove the battery or the wifi card, and boot again, that should work.

Please give us a runtime config method to revert to the former behavior. I encounter the same problem running debian testing on my ASUS laptop. The kernel upgrades several times a year with debian testing. Compiling the kernel each time it upgrades is inconvenient. Thanks. 

(In reply to Yen-Hsuan Chuang from comment #5)
> Hey, the patch enables PCI CLKREQ to reduce power consumption under power
> save state. But it seems like that mech has some inter-op issues with some
> platform.
> 
> Maybe we should add a module parameter or something to disable it after the
> driver is built. But as far as I know, the maintainers aren't going to like
> the module parameters, it makes the maintainence more difficult (they need
> to take care of them in configurations files or something). So, if there is
> a better way to do it please give me a hint. Or if there're too many people
> suffering from it, I can try to use the evil module parameter again, but
> it's when there's no other way we can go.
> 
> Unfortunately, if you want to get the code working, you can just modify the
> code manually. Either revert the patch or return upon the CLKREQ functions
> will do. For example:
> 
> 
> diff --git a/pci.c b/pci.c
> index 9f5edb8e..d9469ebf 100644
> --- a/pci.c
> +++ b/pci.c
> @@ -1199,6 +1199,8 @@ static void rtw_pci_clkreq_set(struct rtw_dev *rtwdev,
> bool enable)
>         u8 value;
>         int ret;
> 
> +       return;
> +
>         ret = rtw_dbi_read8(rtwdev, RTK_PCIE_LINK_CFG, &value);
>         if (ret) {
>                 rtw_err(rtwdev, "failed to read CLKREQ_L1, ret=%d", ret);
> @@ -1218,6 +1220,8 @@ static void rtw_pci_aspm_set(struct rtw_dev *rtwdev,
> bool enable)
>         u8 value;
>         int ret;
> 
> +       return;
> +
>         ret = rtw_dbi_read8(rtwdev, RTK_PCIE_LINK_CFG, &value);
>         if (ret) {
>                 rtw_err(rtwdev, "failed to read ASPM, ret=%d", ret);

> Please give us a runtime config method to revert to the former behavior. I
> encounter the same problem running debian testing on my ASUS laptop. The
> kernel upgrades several times a year with debian testing. Compiling the
> kernel each time it upgrades is inconvenient. Thanks. 

On linux kernel v5.8.3+ (or say, it should contain this commit: [1]), add this setting to a file in /etc/modprobe.d:

options rtw88_pci disable_aspm=1

Then restart. Note that it might only work if your wireless has not been affected with the change. If it's already affected, booting to Windows and connect to a WiFi network usually restores the state of your wireless device.

If you can't have kernel 5.8.3+ due to any reason, use a linux LTS version.

1. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/wireless/realtek/rtw88/pci.c?h=v5.8.3&id=b8e8613492b4b3489dc382a4d1d848af7b2d6a5f

Installed Kernel 5.8.4, 5.8.4-200.fc32.x86_64 to be exact, from standard Fedora repo and added "options rtw88_pci disable_aspm=1" to /etc/modprobe.d/rtw88_pci.conf.

Everything seems to be working well. Hve been ruynning now for 2 days.

Thanks to all involved.

I confirm that 5.8.* kernel on Arch Linux works like a charm.

Thank you!

P.S. I am going to mark the defect as resolved.

I think we should find a way to add a quirk list for the lenovo (or whatever machine that cannot use ASPM) series.

Can anyone help on this ?