I recently installed EndeavourOS on my new laptop and it’s working really well after some tinkering!
However I still have a problem: after resuming from hibernation the WiFi is broken and does not recover on its own. It just keeps trying to connect and then disconnects from the known hotspot.
After some googling I found that reloading the wifi driver can solve my problem:
modprobe -r mt7921e
sleep 1
modprobe mt7921e
This works if I do it manually, but I would like to automate it.
The only way I could find so far is by adding a systemd service and I tried the following.
[Unit]
Description=Restart Wifi afer hibernate
After=hibernate.target
[Service]
Type=oneshot
TimeoutStartSec=10
ExecStart=/bin/bash /home/andreas/reset_wifi.sh
[Install]
WantedBy=hibernate.target
However this doesn’t really work well and it also breaks my system, as it gets stuck during shutdown waiting for this service to complete for some reason…
So my question is if there a way to fix this issue or maybe there is a different solution altogether.
Hello and welcome to 
forums.
Would you be able to try the below code? I changed it a bit.
[Unit]
Description=Run your script after resuming from hibernation
[Service]
Type=oneshot
ExecStart="/bin/bash /home/andreas/reset_wifi.sh"
[Install]
WantedBy=sleep.target
Thanks for the fast response!
Unfortunately this still does not work.
The script seems to get stuck at the first command and afterwards, if I try to ‘modprobe’ manually I always get this response:
modprobe: ERROR: could not remove 'mt7921e': Device or resource busy
Seems like the script is still running.
[Service]
Type=oneshot
TimeoutSec=10
ExecStart="/bin/bash /home/andreas/reset_wifi.sh"
added a TimeoutSec which will combine both TimeoutStartSec and TimeoutStopSec.
One more thing can you try rfkill instead of modprobe.
First, find your wifi.
$ rfkill list wifi
It should look something like below.
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
Then use the below command to disable it.
$ rfkill block 1 <-- use the correct list number you get from the list command
To reenable
$ rfkill unblock 1
Or you can try ip link
Find your wifi interface name.
$ ifconfig
The Wi-Fi name would look something like this wlp3s0
Then to disable
$ ip link set [device] down
To enable
$ ip link set [device] up
Try one of these and see if it works.
I did some more experimenting:
rfkill and the ip command both don’t work for me, the result afterwards is still that the network keeps trying to connect unsuccessfully.
The systemd service with the timeout did seem to work most of the times.
However some times it still seems to get stuck at the first modprobe command and I have problems when i hibernate or shutdown afterwards.
So maybe there is some kind of bug or race condition going on in or around the driver.
This is the journalctl of such an event.
> Mär 31 20:06:46 andreas-swiftsfe1643 systemd[1]: Starting System Hibernate...
> Mär 31 20:06:46 andreas-swiftsfe1643 systemd-sleep[12710]: Performing sleep operation 'hibernate'...
> Mär 31 20:06:46 andreas-swiftsfe1643 kernel: PM: hibernation: hibernation entry
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: Filesystems sync: 0.022 seconds
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: Freezing user space processes
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: page_pool_release_retry() stalled pool shutdown: id 12, 6 inflig>
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: Freezing user space processes failed after 20.006 seconds (1 tas>
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: task:modprobe state:D stack:0 pid:12455 tgid:12455 pp>
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: Call Trace:
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: <TASK>
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: __schedule+0x3e6/0x1520
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? srso_alias_return_thunk+0x5/0xfbef5
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: schedule+0x32/0xd0
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: schedule_timeout+0x151/0x160
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: wait_for_completion+0x86/0x170
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: __flush_work.isra.0+0x173/0x280
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? __pfx_wq_barrier_func+0x10/0x10
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: __cancel_work_timer+0xff/0x190
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? srso_alias_return_thunk+0x5/0xfbef5
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? kfree+0x29f/0x2f0
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? srso_alias_return_thunk+0x5/0xfbef5
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? hrtimer_cancel+0x15/0x40
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: mt7921_pci_remove+0xa0/0x130 [mt7921e f162833d7ef705a946b2732ed>
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: pci_device_remove+0x37/0xa0
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: device_release_driver_internal+0x19f/0x200
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: driver_detach+0x48/0x90
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: bus_remove_driver+0x6d/0xf0
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: pci_unregister_driver+0x42/0xb0
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: __do_sys_delete_module+0x1d2/0x320
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: do_syscall_64+0x86/0x170
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? srso_alias_return_thunk+0x5/0xfbef5
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? __count_memcg_events+0x4d/0xc0
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? srso_alias_return_thunk+0x5/0xfbef5
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? count_memcg_events.constprop.0+0x1a/0x30
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? srso_alias_return_thunk+0x5/0xfbef5
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? handle_mm_fault+0xa2/0x360
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? srso_alias_return_thunk+0x5/0xfbef5
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? do_user_addr_fault+0x304/0x670
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? srso_alias_return_thunk+0x5/0xfbef5
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: ? srso_alias_return_thunk+0x5/0xfbef5
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: RIP: 0033:0x7cbd73727abb
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: RSP: 002b:00007ffd97b57c38 EFLAGS: 00000206 ORIG_RAX: 0000000000>
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: RAX: ffffffffffffffda RBX: 000062627ed78050 RCX: 00007cbd73727abb
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000062627ed780b8
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: RBP: 0000000000000000 R08: 1999999999999999 R09: 0000000000000000
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: R10: 00007cbd7379efe0 R11: 0000000000000206 R12: 00007ffd97b57c80
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: R13: 000062627ed78050 R14: 0000000000000000 R15: 0000000000000000
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: </TASK>
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: OOM killer enabled.
> Mär 31 20:07:07 andreas-swiftsfe1643 kernel: Restarting tasks ... done.
> Mär 31 20:07:07 andreas-swiftsfe1643 rtkit-daemon[892]: The canary thread is apparently starving. Taking acti>
> Mär 31 20:07:07 andreas-swiftsfe1643 rtkit-daemon[892]: Demoting known real-time threads.
> Mär 31 20:07:07 andreas-swiftsfe1643 rtkit-daemon[892]: Demoted 0 threads.
> Mär 31 20:07:07 andreas-swiftsfe1643 systemd-sleep[12710]: Failed to put system to sleep. System resumed agai>
In case anyone else has this problem, I have switched to an Intel AX210 wifi card and the problem has not appeared anymore.