@Charlie_6 According to callahad, downgrading to 6.10 should work.
Since we mailed the issue to the maintainer and regressions@kernel.org, I tried this on 715ca9dd687f89ddaac8ec8ccb3b5e5a30311a99 from torvalds/linux (we’ll be asked for this anyway), and got a similar error, with slightly different output:
Yes, hibernation worked perfectly on 6.10; the regression was introduced with 6.11.
Unfortunately, I cannot easily bisect between 6.10 and 6.11 because I’m running bcachefs which changed its on-disk format with kernel 6.11. Very happy to test patches, though!
Dropping this script into /etc/systemd/system-sleep/rfkill-before-hibernate.sh seems to be a decent workaround in the meantime.
#!/bin/sh
if [ "$1-$SYSTEMD_SLEEP_ACTION" = "pre-hibernate" ]; then
/usr/sbin/rfkill block bluetooth
fi
The patch does not work for me on torvalds/linux HEAD as of an hour ago, but perhaps it will work for you. I’ll post a link to lore or lkml once I can find the conversation in an index.
That’s not to say everything works: I’m having trouble discovering new devices, but haven’t fully investigated it. Maybe it also fails without the patch? Who knows, will investigate further. this seems like a known regression, likely fixed in 6.12-rc4?
Things I’ve observed so far:
Trying discoverable on or scan on in bluetoothctl always fails with Failed to start discovery: org.bluez.Error.InProgress and I’ll see bluetoothd[1145]: Failed to set mode: Busy (0x0a) in the system journal.
Coming out of hibernation, I see the following in the journal:
kernel: mt7921e 0000:05:00.0: Message 00020007 (seq 12) timeout
kernel: mt7921e 0000:05:00.0: PM: dpm_run_callback(): pci_pm_restore returns -110
kernel: mt7921e 0000:05:00.0: PM: failed to restore async: error -110
kernel: PM: hibernation: Basic memory bitmaps freed
kernel: OOM killer enabled.
kernel: Restarting tasks ... done.
kernel: PM: hibernation: hibernation exit
kernel: rfkill: input handler enabled
kernel: rfkill: input handler disabled
bluetoothd[1145]: Controller resume with wake event 0x0
[...]
kernel: Bluetooth: hci0: Device setup in 2378080 usecs
kernel: Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
bluetoothd[1145]: Battery Provider Manager created
kernel: Bluetooth: MGMT ver 1.23
bluetoothd[1145]: src/device.c:device_set_wake_support() Unable to set wake_support without RPA resolution
@callahad, in case you want to say something there, since it worked for you.
I’ll try to see if this patch fixes the issue after deleting everything-- maybe something just didn’t get rebuilt. I see this when I start the build:
====================================== User Patches ======================================
-> Applying user patch 0001-btusb-hao.patch...
patching file drivers/bluetooth/btmtk.c"
I double-checked the paths in the EFI and datestamps on vmlinuz-git+initramfs-git, and it appears to be running what was built this morning with the patch… There could also be something wrong with AUR (en) - linux-git. It’s also possible that something else broke between the last RC and HEAD, but probably somewhat more likely that something is wrong between the keyboard and the chair, as they say.
EDIT: I also tried 6.12-rc3 and read the code myself to make sure the patch was applied correctly by my build script. It was. I just don’t know what to say-- this patch doesn’t fix it for me. Very strange.
@callahad Are you sure that you don’t have any fixes running, such as your sleep hook that runs rfkill?
I’m 110% certain that none of the workarounds were present in the attempts that worked; I did double-check that the rfkill script was not present on patched attempts, but I’m also running NixOS, so the system state is fully declarative and explicit.
I’ve been reluctant to jump into the mailing list until I can properly bisect (which will hopefully be pretty easy on NixOS?) The main blocker there is reformatting to a sensible filesystem that works in both 6.10 and 6.11. Should have a new NVMe drive I can work with in a day or two.
Per the most recent discussion, the kernel patch does not appear to resolve the issue on mainline with this hardware.
Among doing nothing, the rfkill script, and staying at 6.10, that probably depends on your distro and personality. I wouldn’t want to use a distro like Arch too far from mainline-- things will start to break pretty quickly, so my plan is to just remember to press the airplane button before closing the lid until this is fixed. The way I’ve got things set up, it sleeps for an hour before hibernating, so I can always just wake it up and press the button again if I forget. I don’t want to install a sleep hook, because I’ll probably just forget about it and then wonder why my laptop always wakes up with bluetooth off a year from now.
I’d be happy to offer some guidance if you care to share exactly what you’re running.
FWIW, it seems like the sleep hook runs after the systemd service that persists wireless state (systemd-rfkill.service) so my laptop resumes from hibernation with bluetooth on if it was on when the hibernation sequence began.
Working on bisecting, but things are a failing in unexpected ways (some revs won’t boot at all, others won’t finish entering hibernation, etc.) Slowly working through it.
Not a solution, rather a workaround. I tossed something together that is testing nicely on Fedora 41 (6.11 kernel)
Before this, suspend is a no go with Bluetooth enabled.
This script will setup both a rfkill and unblock for Suspend and Hibernate. It’s a workaround.
#!/bin/bash
# Define service files and paths
SUSPEND_SERVICE="/etc/systemd/system/bluetooth-rfkill-suspend.service"
RESUME_SERVICE="/etc/systemd/system/bluetooth-rfkill-resume.service"
# Create and configure the suspend service
echo "Setting up bluetooth-rfkill-suspend.service..."
sudo tee "$SUSPEND_SERVICE" > /dev/null <<EOF
[Unit]
Description=Soft block Bluetooth on suspend/hibernate
Before=sleep.target
StopWhenUnneeded=yes
[Service]
Type=oneshot
ExecStart=/usr/sbin/rfkill block bluetooth
ExecStartPost=/bin/sleep 3
RemainAfterExit=yes
[Install]
WantedBy=suspend.target hibernate.target suspend-then-hibernate.target
EOF
# Create and configure the resume service
echo "Setting up bluetooth-rfkill-resume.service..."
sudo tee "$RESUME_SERVICE" > /dev/null <<EOF
[Unit]
Description=Unblock Bluetooth on resume
After=suspend.target hibernate.target suspend-then-hibernate.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/rfkill unblock bluetooth
[Install]
WantedBy=suspend.target hibernate.target suspend-then-hibernate.target
EOF
# Reload systemd to recognize the new services
echo "Reloading systemd..."
sudo systemctl daemon-reload
# Enable both services
echo "Enabling bluetooth-rfkill-suspend.service..."
sudo systemctl enable bluetooth-rfkill-suspend.service
echo "Enabling bluetooth-rfkill-resume.service..."
sudo systemctl enable bluetooth-rfkill-resume.service
# Suggest reboot to finalize setup
echo "Both Bluetooth rfkill services have been set up and enabled successfully."
echo "It's recommended to reboot now to apply the changes."
# Prompt for reboot confirmation
read -p "Would you like to reboot now? (y/n): " response
if [[ "$response" == "y" || "$response" == "Y" ]]; then
sudo reboot
else
echo "Reboot skipped. Please remember to reboot later to finalize the setup."
fi
Preference. Enable and starting services or restarting services is “fine” until something misfires and fails to be caught, then becoming a ticket. Rare, but happens.
I picked up the latest linux-firmware from Arch, which is dated 2024-11-11, but got a similar panic screen on resume from hibernate. The panic includes the mt7921e firmware build time, which is listed as 20240716163327. I suppose it’s likely that Arch hasn’t picked up this firmware yet somehow. Strange. Am I missing something here?
EDIT: I see this was merged on 11/12, a day after Arch built their firmware release. I’ll wait for the one this week and try it out then.
Sorry for the delay; had a bit of a family emergency.
I can confirm that resuming from hibernation works correctly with the 20241106... firmware builds (on kernel 6.12.1). Unfortunately, those just barely missed the November linux-firmware release, so most folks will be waiting for a few more weeks before things Just Work again.
I’m not totally happy using new firmware to fix a software regression, but it does work, and I’m going to be tracking the latest kernel anyway, so this is a Good Enough resolution for me.
)