NVMe SSD leads to system failure in resuming after suspension.
NVMe SSD leads to system failure in resuming after suspension.
I replaced the SATA M.2 SSD in my Zenbook Duo (UX481 on Debian 12) with an NVMe drive and the issue resurfaced, causing the system to freeze or the drive to become read-only after a short delay. I've tested several workarounds but haven't resolved it. Kernel settings I've adjusted include acpi_rev_override, acpi_osi, mem_sleep_default, iommu, acpiphp.disabled, pcie_aspm, nvme_core, and latency parameters. Have you experienced similar problems with a 1TB Intel 660p or a 512GB Eluktronics drive?
By default it uses s2idle, I attempted to switch to 'deep' but it didn't change much. The 660p is the drive included in this laptop (likely the one I received), though it seems I got it used. I'm running Debian 12, and testing with Debian also produced the same outcome.
The issue with the 660p appears to be consistent across different drives, not just after a change. It seems to affect both the new and old drives. The device is indeed an NVMe storage, not a SATA one. Regarding the sleep states, shallow sleep works and hibernating to disk is a viable option—NVMe drives wake up quickly. You might also want to verify if Linux version 6.6 is compatible, as Debian testing is currently on 6.5.
Hibernation presents an odd problem—it restarts normally but freezes after a short time, crashing or ending with file system errors. It’s hard to install Kernel 6.6 on Debian; I attempted using Zabbly, but it only showed a blinking cursor. Arch and Manjaro don’t recognize the SSD or write to it properly. This drive is solid, but it doesn’t behave consistently across systems, so I’m sticking with the SATA M.2 option for now.
It seems there might be some compatibility issues with your laptop. That can happen sometimes.
Setup for hibernation requires precise configuration. You're checking the power state with "echo mem>/sys/power/state". The command "cat /sys/power/mem_sleep" shows the current memory sleep status. The "/sys/power/sync_on_suspend" flag determines whether the system will synchronize during suspension.
You're encountering a power management issue where sleep commands aren't working as expected. The system returns two sleep options: 's2idle' and 'deep'. It seems the command '/sys/power/sync_on_suspend' might not be properly configured, and setting it to 1 didn't resolve the problem. Checking its status could help clarify if it's enabled or misconfigured.
The text mentions a configuration option in brackets, such as [s2idle]. It suggests checking the kernel documentation for how names relate to states and explains that using "suspend" instead of "hibernate" might affect how the system handles memory management. The process involves adjusting boot settings and verifying the state through commands or logs.