https://bugzilla.kernel.org/show_bug.cgi?id=211585
Bug ID: 211585
Summary: Laptop hangs on second suspend unless a file is
written to second disk
Product: ACPI
Version: 2.5
Kernel Version: 5.10.12-1
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Power-Sleep-Wake
Assignee: [email protected]
Reporter: [email protected]
Regression: No
Description
===========
Acer R13 (R7-371t) with dual SSDs consistently suspends successfully one time
only, fails on the second suspend (hangs/freezes, the screen is black but
keyboard backlight remains on, status LED remains blue and does not switch to
flashing orange as it should during successful suspend). After a failed
suspend, the system will eventually reboot.
After extensive trial and error, I have found that writing a file to the second
SSD prior to suspend resolves the issue.
Investigation
=============
I have been running Ubuntu on the primary disk (Liteon) in my laptop for some
years without issue; suspend worked reliably. Windows 10 was installed on the
second disk (Samsung) and that too had no suspend issues.
I recently installed OpenSuSE Tumbleweed on the Samsung SSD, replacing Windows,
and found that suspending OpenSuSE would hang the system on the second
attempt. I tried the following steps to resolve without success:
+ Changing the boot order of the drives.
+ Smart self tests of the drives (no issues found).
+ Booting to runlevel 3 and suspending
+ Alternative methods of suspending (KDE menu, power button, lid close,
systemctl suspend)
+ Switching X from modesetting driver to intel
+ Checking the kernel logs for errors, removing potentially problematic
modules
Nothing appeared to have any effect. 'journalctl -kxb -1' showed the following
output for a failed suspend (failure to reach syncing filesystems):
kernel: PM: suspend entry (deep)
-- Reboot --
Whereas a successful suspend (first attempt after boot) would show:
kernel: PM: suspend entry (deep)
kernel: Filesystems sync: 0.020 seconds
kernel: Freezing user space processes ... (elapsed
0.001 seconds) done.
...
Workaround
==========
I had read other users with dual disks reporting the same issue, so I opened
the laptop and removed the Liteon disk and moved the Samsung disk into the
first
slot. I booted with just the samsung disk installed. The suspend issue no
longer occurred.
I then opened the laptop again and re-installed the Liteon disk in the second
slot. I booted expecting the issue to be resolved but again the laptop hung on
the second suspend.
I experimented with attempting to suspend while the disk was unmounted or
mounted, occasionally writing a file to the disk to confirm that it was still
functioning. Eventually it dawned on me that a suspend would succeed if a file
had been written to the disk prior to suspend. The following script has
prevented the issue from occurring over many suspends.
/usr/lib/systemd/system-sleep/liteon-keepalive.sleep:
if [ "${1}" == "pre" ]; then
# Do the thing you want before suspend here, e.g.:
echo "we are suspending at $(date)..." > /mnt/data/.keepaliveonsuspend
elif [ "${1}" == "post" ]; then
# Do the thing you want after resume here, e.g.:
echo "...and we are back from $(date)" >> /mnt/data/.keepaliveonsuspend
fi
Hardware/Software Details
=========================
Acer Aspire R13 (R7-371t)
Bios: InsydeH2O Rev.5.0 v1.12
CPU: Intel Core i7-5500U @ 4x 3GHz [49.0°C]
GPU: Mesa DRI Intel(R) HD Graphics 5500 (BDW GT2)
RAM: 5860MiB / 7860MiB
Disks/SSDs:
[1:0:0:0] disk ATA LITEON IT L8T-12 202 /dev/sda
[3:0:0:0] disk ATA Samsung SSD 850 1B6Q /dev/sdb
Distributor ID: openSUSE
Description: openSUSE Tumbleweed
Release: 20210203
OS: openSUSE 20210203
Kernel: x86_64 Linux 5.10.12-1-default
Conclusions
==========
It seems unlikely to me that the Liteon disk is faulty, as I have not had any
other issues with it and it is passing SMART tests. I suspect that either:
+ The disk is not being properly re-initialised after suspend.
+ There is a BIOS or disk firmware issue (no updates are likely to be issued in
future).
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
