I am an Arch user and can confirm that this issue has been resolved as of linux-6.8.7.arch1-2. It was present up to linux-6.8.5.arch1-1. (Please excuse the version jumps as I don’t update very frequently.)
The time it takes for the computer to become responsive upon resume has significantly decreased, making it much more comfortable to use. I’ve also realized that the system used to freeze for a while due to issues with the mt7921e module.
Have updated this morning to kernel 6.8.9-arch1-1, but the problem still persists, in fact it seemed worse, since the system hung up after reloading the mt7921e module (but that could just be an incidental fail, have not tried to repeat this).
Then I switched to 6.6.30-1-lts, and that seems to work without issues. I guess I’ll stay on LTS for a while until this is ironed out.
Have just updated my system to 6.6.31-2-lts, now i have a different problem, my system won’t shutdown/reset, i have to manually powercycle (but wifi does work after resume from hibernate). Tried the new 6.9.1-arch1-2 as well, but there the mt7921e module still needs to be reloaded otherwise there’s no wifi after resume from hibernate. I’m switching back to 6.6.30-1-lts.
This has been my experience with hibernation too: all’s well if I resume within a few hours, but I have to reload the module if it’s left hibernating for longer periods. I haven’t been keeping close track of that but it could be an interesting clue e.g. if the DHCP lease expires while it’s hibernated?
issue persists on Kernel 6.9.1 with NixOS 23.11 & NetworkManager the sudo rmmod mt7921e && sudo modprobe mt7921e actually resolves it. But would be nice for this to just not happen
The interesting thing for me is that it does not seem to happen anymore after I switched from a Fritz!Repeater AP to a Unifi U6+ AP. Also no more sudden deauth errors which were part of the wifi troubles after sleep for me. I’m still keeping an eye open though.
Final solution for me was a /usr/lib/systemd/system-sleep/ script as well.
One interesting point to add: the first version I tried (inadvertently) and had success with just used rfkill block all; sleep 1 in “pre” and sleep 1; rfkill unblock all in “post”.
Next week or so will be testing a version with modprobe and modprobe -r.
Okay: I wanted to follow up and say it’s finally fixed for me. I’m not sure when (I had a mitigation in place), but I’m on 6.10.4 and the wifi comes back without issue.
Personally, to deal with this issue I created a Systemd service called “restart-wifi.service” that runs after hibernation and reinitializes the driver according to the solution here: