I have had Bluetooth disabled in the Gnome settings for a while. Before disabling, every resume from suspend hung. Now that Bluetooth is disabled, it works most of the time but I do still occasionally see what looks like the same hang even with Bluetooth disabled. As usual there seems to be nothing in journalctl after the suspend. I was able to safely reboot this time since I enabled SysReq / REISUB so at least that’s better than having to force an un-safe power down when this happens. Usually I see the SysReq attempts in journalctl, but when I do it after the hang I don’t see those but I know I did them since it did reboot. So something is preventing it from logging anything when the hang happens.
Is anyone else still occasionally seeing the issue even with Bluetooth disabled? I think next maybe I’ll try the systemd service workaround mentioned above to see if that works 100% of the time for me.
Yes, I’ve had the same issue. That’s why I wrote the service and it has been working flawlessly since. Anyway I would just throw out the MediaTek chip if it weren’t under IO shield of my motherboard. That takes too much time
Not sure I can remove it as well… from my Lenovo X13 Gen 2. It is a painful regression, as it impacts a “core feature” for a laptop. It is sad to see comments like “not a distro issue” / “you should report there” in some bug reports, so many bug reports, duplicate, links. Every time it probably makes some users going away from Linux.
If it is a regression, it should be possible to quickly revert the related changes upstream/at packaging level.
Open your laptop and check, I doubt it’s soldered to the board. You will need to find which PCI keyout you have and then you order Intel AX210 with the same keyout for about 10 - 15$ and you are done. 0 MediaTek chips in your laptop
Laurent, I feel your frustration. I’ve spent so much time here, reddit and the Arch forums reading about this issue. I’ve dug through Fedora bug reports as well as kernel bug reports and added myself to the notification of every one. It doesn’t seem like anyone is working on this and I am not seeing any forward progress (other than the workaround) on any of the bugs.
After struggling with this for the last month (and even switching to windows for a while) I finally decided to try unofficial LTS kernel from copr. Everything just works, I can finally use my computer and not worry about forgetting to shut it down. It also boots faster… I think I’m gonna be staying on LTS kernels from now on and will switch my laptop to that too.
Nevermind. I had flashed a new BIOS troubleshooting some other issues and it turns out my Bluetooth just wasn’t worked at all . Still broken for me on 6.12.1.
Even though there are a bunch of bug reports on this, it doesn’t seem like Mediatek is even working on this. I subscribed to all the bug reports I could find and none of them are progressing.
Here is one of the bug reports. I suggest anyone having the issue update this one with as many helpful details about your failure as you can and subscribe to updates:
Is anyone who is using the systemd rfkill workaround having issues that after several suspend/resumes that your apps indicate they are not responding yet can’t be killed or you’re out of memory? I don’t know if it’s related to the workaround but it started around the same time as I started using the workaround. I documented what I’m seeing in this post so we can treat it as a separate issue:
Thanks, bug report 219514 is great in that the submitter bisected it and found the exact commit and lines to change for a fix! I had searched for kernel bugs related to suspend a while back, but either I missed this one or it wasn’t filed at the time. Let’s hope we get someone from Mediatek to respond to that bug as I haven’t seen any acknowledgement or engagement of them on any of the other bugs on this issue.
I think it was fixed in kernel 6.12.8, I’ve seen a few commits from MediaTek on the Bluetooth topic and decided to disable the service I have written as a workaround. Sleep is working.
It will show up as an update in a few days, if you are eager to try it out now, use the command in here and feel free to drop a message that it’s finally fixed in that thread as well if it works out for you. https://bodhi.fedoraproject.org/updates/FEDORA-2025-dbab3ac043