If anyone (@c6fcef92?) is curious, I probably “broke” resume on my laptop when I replaced the secondary SATA disk. The timing changed slightly, and I'm hitting a deadlock that shouldn't happen.
https://marc.info/?l=linux-pm&m=169634614718495&w=2
@c6fcef92 Yeah, I realized I was able to trigger a crash dump with SysRq+c, even though my screen was blank or scrambled.
Congrats on your finding. My case is different. I know that it is somehow related to my NVMe disk. I can see blk_queue_enter() waiting for an event which never arrives.…
It only happens on battery power, so I'm going to check if it also fails after turning off autosuspend.
@c6fcef92 That's it! My laptop has just survived 10 suspend-resume cycles on battery power with autosuspend off, but it hanged on the first attempt on AC power with autosuspend enabled.
Is it too cynical to expect that (some) distributions would fix the issue by adding the following command to their suspend hook?
echo on > /sys/bus/scsi/devices/0\:0\:0\:0/power/control
@c6fcef92 Yeah, I realized I was able to trigger a crash dump with SysRq+c, even though my screen was blank or scrambled.
Congrats on your finding. My case is different. I know that it is somehow related to my NVMe disk. I can see blk_queue_enter() waiting for an event which never arrives.…
It only happens on battery power, so I'm going to check if it also fails after turning off autosuspend.
@c6fcef92 Oooh. I'm performing a post-mortem crash dump analysis using drgn on my Thinkpad E595 running #opensuse #tumbleweed. Broken resume, too. But mine broke with 6.5 already…
Notes by Petr Tesarik | export