No more wifi after suspend on honor magicBook 14 2020
Linux - Laptop and NetbookHaving a problem installing or configuring Linux on your laptop? Need help running Linux on your netbook? This forum is for you. This forum is for any topics relating to Linux and either traditional laptops or netbooks (such as the Asus EEE PC, Everex CloudBook or MSI Wind).
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
No more wifi after suspend on honor magicBook 14 2020
Hi all,
I have an Honor magicBook 14 (2020) laptop running Fedora 33.
Everything works perfectly except when waking up from suspend. When that happens, no more wifi and lots of log errors. The only solution to recover the wifi: reboot. I can restart networkmanager, nothing change. The wifi part is still down.
The model is so new that I can't find any info on the web about it. The processor is a Ryzen 4500u with a Realtek rtl8822ce network card.
I understand it's a problem of power state change of the wifi card.
I admit that it becomes too technical for me and I find it difficult to understand what exactly is going on.
Is it the wifi card that is causing the problem or maybe it's still upstream on the PCI part?
If anyone has any idea on this issue that would be great.
Thank you in advance !
Here are the error logs:
Code:
sudo journalctl -p err
janv. 01 19:35:27 kernel: pcieport 0000:00:01.2: can't change power state from D3hot to D0 (config space inaccessible)
janv. 01 19:35:27 kernel: rtw_8822ce 0000:01:00.0: can't change power state from D3hot to D0 (config space inaccessible)
janv. 01 19:35:27 kernel: rtw_8822ce 0000:01:00.0: failed to poll offset=0x5 mask=0x2 value=0x0
janv. 01 19:35:27 kernel: rtw_8822ce 0000:01:00.0: mac power on failed
janv. 01 19:35:27 kernel: rtw_8822ce 0000:01:00.0: failed to power on mac
janv. 01 19:35:27 kernel: PM: dpm_run_callback(): wiphy_resume+0x0/0x120 [cfg80211] returns -114
janv. 01 19:35:27 kernel: PM: Device phy0 failed to resume async: error -114
janv. 01 19:35:29 abrt-notification[2633]: System encountered a non-fatal error in amdgpu_dm_backlight_update_status()
janv. 01 19:35:29 kernel: rtw_8822ce 0000:01:00.0: failed to poll offset=0x5 mask=0x2 value=0x0
janv. 01 19:35:29 kernel: rtw_8822ce 0000:01:00.0: mac power on failed
janv. 01 19:35:29 kernel: rtw_8822ce 0000:01:00.0: failed to power on mac
janv. 01 19:35:30 abrt-notification[2643]: System encountered a non-fatal error in _cond_resched()
janv. 01 19:35:31 abrt-notification[2652]: System encountered a non-fatal error in ieee80211_do_stop()
janv. 01 19:35:32 wpa_supplicant[844]: Could not set interface wlp1s0 flags (UP): Operation already in progress
janv. 01 19:35:32 kernel: rtw_8822ce 0000:01:00.0: failed to poll offset=0x5 mask=0x2 value=0x0
janv. 01 19:35:32 kernel: rtw_8822ce 0000:01:00.0: mac power on failed
janv. 01 19:35:32 kernel: rtw_8822ce 0000:01:00.0: failed to power on mac
janv. 01 19:35:32 wpa_supplicant[844]: nl80211: Could not set interface 'wlp1s0' UP
janv. 01 19:35:32 abrt-notification[2662]: System encountered a non-fatal error in ieee80211_do_stop()
janv. 01 19:35:34 wpa_supplicant[844]: Could not set interface wlp1s0 flags (UP): Operation already in progress
janv. 01 19:35:34 kernel: rtw_8822ce 0000:01:00.0: failed to poll offset=0x5 mask=0x2 value=0x0
janv. 01 19:35:34 kernel: rtw_8822ce 0000:01:00.0: mac power on failed
janv. 01 19:35:34 kernel: rtw_8822ce 0000:01:00.0: failed to power on mac
janv. 01 19:35:34 NetworkManager[769]: <error> [1609526134.1560] device (wlp1s0): Couldn't initialize supplicant interface: GDBus.Error:fi.w1.wpa_supplicant1.U>
janv. 01 19:35:34 wpa_supplicant[844]: WEXT: Could not set interface 'wlp1s0' UP
janv. 01 19:35:34 wpa_supplicant[844]: wlp1s0: Failed to initialize driver interface
janv. 01 19:35:46 wpa_supplicant[844]: Could not set interface wlp1s0 flags (UP): Operation already in progress
etc...
And informations abaout my configuration if needed :
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Root Complex
Subsystem: QUANTA Computer Inc Device 126b
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Renoir IOMMU
Subsystem: QUANTA Computer Inc Device 126b
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge
Kernel driver in use: pcieport
00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
00:02.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP Bridge
Kernel driver in use: pcieport
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus
Kernel driver in use: pcieport
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 51)
Subsystem: QUANTA Computer Inc Device 126b
Kernel driver in use: piix4_smbus
Kernel modules: i2c_piix4, sp5100_tco
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
Subsystem: QUANTA Computer Inc Device 126b
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 3
Kernel driver in use: k10temp
Kernel modules: k10temp
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 5
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 6
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir Device 24: Function 7
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8822CE 802.11ac PCIe Wireless Network Adapter
Subsystem: Electronics & Telecommunications RSH Device 1e25
Kernel driver in use: rtw_8822ce
Kernel modules: rtw88_8822ce
02:00.0 Non-Volatile memory controller: Sandisk Corp WD Blue SN550 NVMe SSD (rev 01)
Subsystem: Sandisk Corp WD Blue SN550 NVMe SSD
Kernel driver in use: nvme
Kernel modules: nvme
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Renoir (rev c3)
Subsystem: QUANTA Computer Inc Device 126b
Kernel driver in use: amdgpu
Kernel modules: amdgpu
03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device 1637
Subsystem: QUANTA Computer Inc Device 126b
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
03:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security Processor
Subsystem: QUANTA Computer Inc Device 126b
Kernel driver in use: ccp
Kernel modules: ccp
03:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Renoir USB 3.1
Subsystem: QUANTA Computer Inc Device 126b
Kernel driver in use: xhci_hcd
03:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Renoir USB 3.1
Subsystem: QUANTA Computer Inc Device 126b
Kernel driver in use: xhci_hcd
03:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD] Raven/Raven2/FireFlight/Renoir Audio Processor (rev 01)
Subsystem: QUANTA Computer Inc Device 126b
Kernel modules: snd_pci_acp3x, snd_rn_pci_acp3x
03:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller
Subsystem: QUANTA Computer Inc Device 126b
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
Then, I did the maipulation of deactivating / activating the rtw88_8822ce module (waiting a few seconds between) then restarting Netwokmanager: but nothing helped.
Here are the errors, always with the famous "can't change power state from D3hot to D0 (config space inaccessible)".
Code:
janv. 04 19:55:23 kernel: rtw_8822ce 0000:01:00.0: can't change power state from D3hot to D0 (config space inaccessible)
janv. 04 19:55:23 kernel: rtw_8822ce 0000:01:00.0: mac power on failed
janv. 04 19:55:23 kernel: rtw_8822ce 0000:01:00.0: failed to power on mac
janv. 04 19:55:23 kernel: rtw_8822ce 0000:01:00.0: failed to setup chip efuse info
janv. 04 19:55:23 kernel: rtw_8822ce 0000:01:00.0: failed to setup chip information
One more thing. Do you have fast boot enabled on the machine? (UEFI or BIOS) setup.
Dual booting with windows? Windows can leave hardware in a quasi weird state. Hence, make windows shut down all the way down.
My bios options are really minimal and I don't have an option to enable or disable fastboot.
For Windows, indeed, I have it in double boot (to be able to update the bios if necessary) but I do not use it.
In any case, I had to boot and reboot the machine on Fedora about 30 times since the last time I started Windows. I think it no longer acts negatively.
Finally, for the subject of the kernel, I see the idea but I am not yet able to patch, recompile or tweak myself unfortunately
here is the output of rfkill:
Code:
sudo rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
There's usually a key combination for activating and deactivating wireless. After booting and having wireless come up, try deactivating and then activating just to see if you can bring wireless back up after deactivating. If you can do that successfully, try deactivating wireless before suspending and then reactivating after resuming. If that works, you can try suspending as usual and on resume, deactivate and reactivate and see if wireless comes up.
Good idea your method. I tried and unfortunately it didn't work.
As long as the PC has not been suspended, all is well. I can deactivate / activate wifi (via the "airplane mode" button) without any problem. everything is going well.
On the other hand, I deactivate the network, I suspend, and when I return from suspend: impossible to reactivate. I still have the same error in the logs
I'm having the exact same problem with the exact same laptop (Honor Magicbook 14 2020, AMD Ryzen 5 4500U), running Arch. I have tried everything mentioned here so far but no miracle :/
I have also tried running the LTS 5.10 arch kernel, as well as the current one, 5.14.
I'm very happy to find this thread, as I have been struggling with this myself, running openSUSE Leap 15.3, with default kernels.
I can confirm that the usual module removing and re-installing tricks do not work on the issue. It's as though the wireless hardware no longer exists after suspending.
I made a little progress by following one set of advice which made two suggestions, one of which "feels" right, and that was to add these lines to /etc/NetworkManager/NetworkManager.conf:
But the real change came with a suggestion about turning off iommu. I have only had time to try one such setting, adding "amd_iommu=fullflush" to grub, after which, on one occasion. wifi came up quickly after a suspend. I am not yet certain whether this grub line needs rto be "amd_iommu" or just "iommu", which I think may be Intel-related. Also, it seems there are security implications of simply switching off iommu.
Also, after suspending, it's worth while noting that a "journalctl -f" has an entry to the effect that the hardware is no longer there.
I do run tlp, and need to check to see if some sleep state from tlp is affecting the hardware. I am also wondering whether it is worth trying setting some parameters to the rtw88_core module in /etc/modprobe.d. I suspect not, if the old module removal and re-install doesn't work, and that more hardware-related iommu setting may bear more fruit.
OK, I've done a little more testing, and in some ways I'm no further forward, but maybe a pointer or two can help someone else more knowledgeable.
The problem is that the hardware does not wake up after a suspend. The journald entry is quite clear
Quote:
Oct 12 15:46:58 hobo kernel: rtw_8822ce 0000:01:00.0: failed to poll offset=0x5 mask=0x2 value=0x0
Oct 12 15:46:58 hobo kernel: rtw_8822ce 0000:01:00.0: mac power on failed
Oct 12 15:46:58 hobo kernel: rtw_8822ce 0000:01:00.0: failed to power on mac
This explains why attempting to re-install the relevant modules doesn't work - there's nothing there as far as the hardware is concerned.
However, just playing around with various options, if I boot and include in the grub line "iommu=off", the machine starts, but with no wifi. It's as though the hardware isn't there; in other words, it feels rather similar to the situation after suspending. This is the fact I am hoping someone more knowledgeable can extrapolate from.
It seems the "iommu=fullflush" option is now deprecated. The more correct format is now "iommu.strict=1". This is also an interesting option. It usually fails to resolve the problem, but if you reboot with this grub option, then immediately suspend, wifi works properly and suspend is fully functional. Wait an extra minute or so, and suspend fails. It makes me wonder if some process, possibly to do with power saving, happens during that time, but I have not been able to find it.
Also, just for completeness, it does not seem to matter is you use iommu or amd_iommu, although it is possible that these do different things - I'm no kernel guru, and reading about these options and associated acronyms makes my head spin.
Other options which had no effect were "iommu=soft" and "iommu=pt" or its latest preferable option "iommu.passthrough=1".
The next port of call may be to find some settings in the modules themselves. For example, rtw88_core has a parameter, which you can see if you do a a"modinfo rtw88_core" (some systems name the modules slightly differently, I think):
Quote:
parm: lps_deep_mode: Deeper PS mode. If 0, deep PS is disabled (uint)
I can't help but wonder if supporting a deeper sleep mode may affect coming back from the dead, which is what seems to be the trouble here. Similar the module rtw88_pci has these options:
Quote:
parm: disable_msi:Set Y to disable MSI interrupt support (bool)
parm: disable_aspm:Set Y to disable PCI ASPM support (bool)
Again, I don't know exactly what those do, but one can see that the issue enumerating the hardware after a suspend /may/ be affected by one of those.
Gah! It feels so close to a solution.... I do hope someone is able to build on these observations.
OK, I think I have a workaround to this problem. The more I tried various options to invoke a known change, in an effort to understand this better, the more it felt like something to do with the driver. So I tried manually removing all the wifi modules and suspending, then adding them again when the system woke up. Amazingly, the wireless fired up. I tried again, and once again, it worked perfectly. So it is a workaround, but seems to resolve the issue.
To make it work every time, I added an executable script to /usr/lib/systemd/system-sleep. I called the script wifi-suspending.sh but the name doesn't matter. The file contains:
Don't forget to "chmod +x" to make it executable. I restarted at this point and tested again.
Note that I have removed the entire stack of modules, but it's only necessary to add the main driver, which brings in the others automatically. Also, I have not bothered to see if I can just remove one of those modules, ie, the problematic one only. I don't think there's any harm in cleaning out the whole problematic stack, though, in a workaround like this.
Thanks to polnareff for starting this thread, as this issue has been bugging me since I got my magicbook, which is otherwise a fabulous machine. But I still think this is a workaround rather than a solution.
Reporting that the solution in the message #14 by QuaintLizard works on Honor Magicbook 14 running OpenSUSE Tumbleweed. Although I did 3-4 suspends so far, but it works!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
