Package: linux-image-6.12.85+deb13-amd64 Severity: normal X-Debbugs-Cc: debian-amd64@lists.debian.org User: debian-amd64@lists.debian.org Usertags: amd64 Dear Debian kernel team, I upgraded from bookworm to trixie and now suspend-to-disk does not work correctly anymore. echo disk > /sys/power/state suspend the computer, it seems to resume correclty but then immediatly crashes. My laptop is a Dell latitude 5410. Cheers,
Control: tags -1 + moreinfo Before we start into deeper debugging, can you check if like for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1135599#51 reverting the offending commit fixes your issue? The offending commit went in almost all stable series, 6.12.75 has it as well, so the current trixie kernel. Regards, Salvatore
Hi Bill, Regards, Salvatore
Hi Bill, Please skip the revert attempt. Havin a cashlog would ideally be the best good start. The offending commit does not need a revert in 6.12.y based on the discussion in https://lore.kernel.org/regressions/58f6e74d-480e-4e0c-aa66-68dfc1de7421@leemhuis.info/ Regards, Salvatore
How do I do that reliably ? For what I see, it crashes just after kernel: PM: hibernation: hibernation exit Cheers,
In fact it is even weirder: 'echo disk > /sys/power/state' -> it hibernates First restart -> it resumes (displays the correct screen) and then halts Second restart -> it resumes again and then FAIL. I tried some other kernels from snapshot.debian.org 6.1.0-44 -> very good 6.5.0-0.deb12.4 -> good 6.10.11+bpo -> exit hibernation immediatly, does not halt (bad) 6.12.9+bpo -> idem (bad) 6.12.43+deb12 -> idem (bad) 6.12.69+deb12 -> idem (bad) 6.12.74+deb12 -> idem (bad) So actually 6.12.85 goes farther... Cheers,
Any idea what I should try ? Cheers,
Bill, can you provide a fresh boot kernel log and output of `lspci -nnk`
(for any kernel version that fails a hibernation resume).
You can get a list of boot session UUIDs and the kernel used with
`journalctl --grep 'Linux version' `
Then use `journalctl --boot ${UUID} > dmesg.log `
6.7.12-1~bpo12+1 -> OK 6.8.9 -> exit hibernation immediatly, does not halt (bad) 6.8.12-1 -> idem (bad) I note that if we do 'echo disk > /sys/power/state' repeatedly, then it crashes but after a hard reboot it recovers the state correctly! 7.0.7+deb13 -> suspend but does not recover. Cheers,
Hi Bill, Thanks for the bisection effort -- narrowing it to 6.7 OK -> 6.8 bad is useful. However, We still need more information to move forward. I understand collecting logs is difficult when the machine appears dead after resume, so here is a guide broken into steps. (1) Provide fresh system information We do not have your exact machine. We need hardware, driver, and firmware details to cross-reference changes between 6.7 and 6.8. Please attach the output of the following (from a fresh boot with a failing kernel): uname -a cat /proc/cpuinfo | head -20 lspci -nnk lsmod dmesg > dmesg-fresh-boot.log journalctl -b 0 > journal-fresh-boot.log fwupdmgr get-devices You can check it from previous mailing thread from Salvatore and TJ (Thanks!):------ (2) Determine if the kernel panics or only the display freezes Before setting up crash dumps, check whether the kernel is actually dead or just the display stopped updating. Before triggering hibernate, start a persistent log watcher: journalctl -kf > /tmp/hibernate-watch.log 2>&1 & Then trigger your scenario. After the machine appears stuck, from another machine on the same network: ping <your-laptop-ip> If it responds: the kernel is alive, only the display is frozen. You can SSH in and collect logs (journalctl, dmesg). If it does not respond: the kernel has likely panicked. Proceed to step 3. (3) Capture crash dump with kdump If the machine is completely unresponsive (no ping), install kdump to capture the panic log: sudo apt install kdump-tools Reboot once after installation (kdump reserves memory at boot). Then reproduce your hibernate scenario. If the kernel panics, kdump will write a dump to /var/crash/. After the machine reboots: ls /var/crash/ Attach the dmesg file from that crash directory. If you can also attach the full vmcore dump, even better, but the dmesg alone is sufficient to start. With the hardware info from step 1 and the bisection range (6.7 -> 6.8), we can look at the specific commits affecting your hardware. The logs or crash dump will tell us exactly what is failing on resume. Sorry for the late reply! :) Best Regards, Yunseong
Hi Bill, Thanks for the bisection effort -- narrowing it to 6.7 OK -> 6.8 bad is useful. We still need more information to move forward. I understand collecting logs is difficult when the machine appears dead after resume, so here is a guide broken into steps. (1) Provide system information We do not have your exact machine. We need hardware, driver, and firmware details to cross-reference changes between 6.7 and 6.8. Please attach the output of the following (from a fresh boot with a failing kernel): uname -a cat /proc/cpuinfo | head -20 lspci -nnk lsmod dmesg > dmesg-fresh-boot.log journalctl -b 0 > journal-fresh-boot.log fwupdmgr get-devices You can check those previous mailing thread (Thanks Salvatore and TJ) :------ (2) Determine if the kernel panics or only the display freezes Before setting up crash dumps, check whether the kernel is actually dead or just the display stopped updating. Before triggering hibernate, start a persistent log watcher: journalctl -kf > /tmp/hibernate-watch.log 2>&1 & Then trigger your scenario. After the machine appears stuck, from another machine on the same network: ping <your-laptop-ip> If it responds: the kernel is alive, only the display is frozen. You can SSH in and collect logs (journalctl, dmesg). If it does not respond: the kernel has likely panicked. Proceed to step 3. (3) Capture crash dump with kdump If the machine is completely unresponsive (no ping), install kdump to capture the panic log: sudo apt install kdump-tools Reboot once after installation (kdump reserves memory at boot). Then reproduce your hibernate scenario. If the kernel panics, kdump will write a dump to /var/crash/. After the machine reboots: ls /var/crash/ Attach the dmesg file from that crash directory. If you can also attach the full vmcore dump, even better, but the dmesg alone is sufficient to start. With the hardware info from step 1 and the bisection range (6.7 -> 6.8), we can look at the specific commits affecting your hardware. The logs or crash dump will tell us exactly what is failing on resume. Sorry for the late reply! :) Regards, Yunseong
The problem with the bisection is that the behaviour changed between 6.12.74 and 6.12.86, 6.12.74 does not suspend but recover (after a hard shutdown) while 6.12.86 suspends recover but then stop. So which kernel should I use for reporting the log ? Thanks, I did not receive this mail, I was not CCed. Cheers, Bill.
Hi Bill, I remember you mentioned:--- 6.1.0-44 -> very good 6.5.0-0.deb12.4 -> good 6.10.11+bpo -> exit hibernation immediatly, does not halt (bad) 6.12.9+bpo -> idem (bad)--- 6.7.12-1~bpo12+1 -> OK 6.8.9 -> exit hibernation immediatly, does not halt (bad) 6.8.12-1 -> idem (bad)--- I think you can share either 6.10.11+bpo or 6.8.9. I suspect those versions also have the similar issue. It seems that both versions have issues. Could you please share each 2 items information? I those kernel maybe hung not panicked. I want to check whether the kernel is still alive or has panicked and crashed. * Don't forget to sharing fresh information: hardware, driver, firmware mentioned at the previous thread. * Don't forget to set it up before triggering hibernation, start a persistent log watcher: journalctl -kf > /<e.g., your $HOME>/hibernate-watch.log 2>&1 & I've updated the command because it was confusing in the /tmp directory. Regards, Yunseong
Thanks for going back to me! With 6.8.9, either echo disk > /sys/power/state do nothing at all or (when repeated) it cause a kernel panic. Despite the panic, after a hard reboot, the system resume from hibernation, exactly as if echo disk > /sys/power/state had worked. With 6.12.86, this is completly different. echo disk > /sys/power/state suspends the system. the system resumes correctly but immediatly stop. after a reboot it resumes again and then fails immediately I attach data for uname -a Linux seventeen 6.1.0-48-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.172-1 (2026-05-15) x86_64 GNU/Linux (which works) before I reboot to 6.12.88. Cheers, Bill.
Hi Bill, Your shared file is missing important information for approaching this issue. We need the *currently loaded kernel module* and *kernel log*. As I've mentioned from previous mail thread: $ lsmod $ journalctl -b 0 > journal-fresh-boot.log $ journalctl -kf > hibernate-watch.log 2>&1 & After reboot, Can you attach those log file? Thanks! Regards, Yunseong
Sorry, it took me some time. Please find the data for 6.12.88+deb13, which suspends fine but fails ater resume. Cheers,
Hi Bill, No problem, Please take your time. As a fellow Dell user, it’s an interesting and pesky bug. If you can share the kernel log and the output of lsmod, I can check the relevant changes/patches in the stable kernel release version and compare the differences. Thanks! Regards, Yunseong
This should be in the tarball I attached in the previous email. (Maybe Debian should provide a tool to generate such report) Cheers,
Hello again Bill, Thank you, It is really helpful. Could you try it on the problematic kernel? # Unload bluetooth kernel driver modprobe -r btusb btintel # your scenario echo disk > /sys/power/state suspends the system. # resumes system, an reload bluetooth kernel driver modprobe btusb I’ll check with the other Debian Kernel Team members, though most of Debian kernel bug report use a similar report form. I’ll also check how they summarize this information. Thanks! Best Regards, Yunseong
Well the system suspends, resumes then halts immediately after resuming. When I reboot it, it resume agains then halt, etc. But at least it does not display 'FAILED' before halting. I join the log. Cheers
Hi Bill, Can you try this way? sudo usermod -a -G power $USER # kernel parameter i915.enable_psr=0 mem_sleep_default=deep snd_hda_intel.dmic_detect=0 intel_idle.max_cstate=1 i915.enable_dc=0 Link: https://www.linkedin.com/pulse/fixing-sleepsuspend-dell-latitude-54xx-linux-hemish-mononymous/ Best regards, Yunseong
Hello Yunseong, The group power does not exist on Debian. Unfortunately the post does not say which kernel was tested. It does not hurt to try but it look like a different issue. Cheers, Bill.
Since the Debian kernel has CONFIG_PM_DEBUG=y can you follow the various tests described in the kernel's "Debugging hibernation and suspend" instructions: https://docs.kernel.org/power/basic-pm-debugging.html and report anything significant from logs.