Kernel 6.11.3-200.fc40 unable to resume from suspend when bluetooth enabled

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.

Anyone tried 6.12.1 kernel? A build is already on koji
https://koji.fedoraproject.org/koji/packageinfo?packageID=8

I installed 6.12.1-200 on fedora 41 and my suspend problems are gone. Waiting to see if any other issues arise, but so far so good.

1 Like

Nevermind. I had flashed a new BIOS troubleshooting some other issues and it turns out my Bluetooth just wasn’t worked at all :frowning:. Still broken for me on 6.12.1.

You got my hope up and smashed it back down :slight_smile:

Seriously though, appreciate you checking.

Today, I just noticed an update of package mt7xxx-firmware.

Name : mt7xxx-firmware
Version : 20241210
Release : 1.fc41
Architecture: noarch
Install Date: ven. 13 déc. 2024 07:27:54

In the changelog:

  • mediatek MT7921/MT7922: update bluetooth firmware

Maybe I’ll remove the mitigation configured using systemd and see what happens…

I’ve updated the firmware and disabled the system service and the sleep is still broken. Enabling the service again…

If anyone’s still tracking, this is still an issue for me with 6.12.4-200.fc41.x86_64 using a MediaTek Bluetooth 0e8d:0616 device.

2 Likes

Just tried kernel 6.12.6 and it’s still not fixed. Is MediaTek even aware of this issue?

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:

https://bugzilla.kernel.org/show_bug.cgi?id=219290

If anyone has any other ideas how to get Mediatek to fix this please do those too!

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.

I believe this bug report would need to be reported as something else entirely, seeing it started as a GPU bug report. I’ll do that.

EDIT: This one is way better (not mine): 219514 – PC does not resume from suspend, bisect points to btusb/mediatek

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.

1 Like

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

1 Like

Do you have a direct link to those commits?