NVMe SSD causes system to no longer be able to resume from suspend

[Mnky313]

I swapped out the SATA M.2 SSD I had in my Zenbook Duo (UX481 running Debian 12) for an NVMe one and now resuming causes the drive to either disconnect or become read only after a few seconds causing the system to freeze/hang.

I've tried a bunch of workarounds but nothing has fixed the issue.

kernel parameters I've tried:

acpi_rev_override=1
acpi_osi=Linux
mem_sleep_default=deep
iommu=soft
acpiphp.disabled=1
pcie_aspm=disabled
nvme_core.default_ps_max_latency_us=0
nvme.noacpi=1

Any other ideas?

I've had the same problem on a 1TB Intel 660p and now a 512GB Eluktronics branded drive.

[Sauron]

Could you specify the distribution you're using? Which drive came with the laptop and which drive did you swap in? (I see you've specified others you tried but not the original one you wanted to put in)

 

"Suspend" can refer to a variety of states in Linux, as mentioned in the arch wiki:

Quote

There are multiple methods of suspending available, notably:

Suspend to idle

Called S0ix by Intel, Modern Standby (previously "Connected Standby") by Microsoft and S2Idle by the kernel. Designed to be used instead of the S3 sleeping state for supported systems, by providing identical energy savings but a drastically reduced wake-up time.

Tip: While this state is subject to battery drain issues on Windows or macOS since they support waking devices in this state for network activity, the Linux software ecosystem does not currently make use of this feature and should be unaffected.

Suspend to RAM (aka suspend, aka sleep)

The S3 sleeping state as defined by ACPI. Works by cutting off power to most parts of the machine aside from the RAM, which is required to restore the machine's state. Because of the large power savings, it is advisable for laptops to automatically enter this mode when the computer is running on batteries and the lid is closed (or the user is inactive for some time).

Suspend to disk (aka hibernate)

The S4 sleeping state as defined by ACPI. Saves the machine's state into swap space and completely powers off the machine. When the machine is powered on, the state is restored. Until then, there is zero power consumption.

Hybrid suspend (aka hybrid sleep)

A hybrid of suspending and hibernating, sometimes called suspend to both. Saves the machine's state into swap space, but does not power off the machine. Instead, it invokes the default suspend. Therefore, if the battery is not depleted, the system can resume instantly. If the battery is depleted, the system can be resumed from disk, which is much slower than resuming from RAM, but the machine's state has not been lost.

The kernel provides basic functionality, and some high level interfaces provide tweaks to handle problematic hardware drivers/kernel modules (e.g. video card re-initialization).

Do you know which one you're using? As a workaround you could try using a different suspend state.

[Mnky313]

6 hours ago, Sauron said:

Could you specify the distribution you're using? Which drive came with the laptop and which drive did you swap in? (I see you've specified others you tried but not the original one you wanted to put in)

 

"Suspend" can refer to a variety of states in Linux, as mentioned in the arch wiki:

Do you know which one you're using? As a workaround you could try using a different suspend state.

By default it's using s2idle, tried switching to 'deep' but that didn't make a difference

the 660p is the drive that shipped in this laptop (presumably, I got it used but that's what came with it).

I'm on Debian 12, also tried Debian testing with the same results.

[Sauron]

2 hours ago, Mnky313 said:

the 660p is the drive that shipped in this laptop (presumably, I got it used but that's what came with it).

Sorry but I'm a little confused - you said the 660p also has this problem, so was it present from the start or did it only begin after you changed the drive and now happens with the old drive as well? Also as far as I know the 660p is an nvme drive, not sata.

 

Just to check all options, does the "shallow" sleep state work?

 

Hibernating to disk could also be a good alternative, with an nvme drive wake-up should be pretty fast regardless.

 

Finally, you could check whether linux 6.6 works. As far as I can tell, debian testing is on 6.5.

[Mnky313]

17 minutes ago, Sauron said:

Sorry but I'm a little confused - you said the 660p also has this problem, so was it present from the start or did it only begin after you changed the drive and now happens with the old drive as well? Also as far as I know the 660p is an nvme drive, not sata.

 

Just to check all options, does the "shallow" sleep state work?

 

Hibernating to disk could also be a good alternative, with an nvme drive wake-up should be pretty fast regardless.

 

Finally, you could check whether linux 6.6 works. As far as I can tell, debian testing is on 6.5.

It was present from the start, yes.

I don't have 'shallow', only 's2idle' and 'deep' (as read from /sys/power/mem_sleep)

I'll give hibernation a shot and see what happens.

Same with kernel 6.6, I'll give it a try and report back

[Mnky313]

2 hours ago, Sauron said:

Sorry but I'm a little confused - you said the 660p also has this problem, so was it present from the start or did it only begin after you changed the drive and now happens with the old drive as well? Also as far as I know the 660p is an nvme drive, not sata.

 

Just to check all options, does the "shallow" sleep state work?

 

Hibernating to disk could also be a good alternative, with an nvme drive wake-up should be pretty fast regardless.

 

Finally, you could check whether linux 6.6 works. As far as I can tell, debian testing is on 6.5.

Hibernation has  the same issue which is very weird, it resumes fine but after a few seconds it locks up or dumps me to the console with file system errors.

I can't get anything we Kernel 6.6 to even install... I tried using Zabbly to update to kernel 6.6 on debian but that didn't boot, just got stuck on a blinking cursor.

Arch and Manjaro both fail to either see the SSD at all or write to it... This is a known good drive, it works perfectly fine in another system so for now I'll just stick with the SATA M.2

[Sauron]

1 hour ago, Mnky313 said:

Hibernation has  the same issue which is very weird, it resumes fine but after a few seconds it locks up or dumps me to the console with file system errors.

I can't get anything we Kernel 6.6 to even install... I tried using Zabbly to update to kernel 6.6 on debian but that didn't boot, just got stuck on a blinking cursor.

Arch and Manjaro both fail to either see the SSD at all or write to it... This is a known good drive, it works perfectly fine in another system so for now I'll just stick with the SATA M.2

Interesting. I wonder if it's just not fully compatible with your specific laptop, sometimes that happens.

[Ralphred]

On 1/15/2024 at 8:58 PM, Mnky313 said:

Hibernation has  the same issue which is very weird

Hibernation needs a specific set-up to work properly.

How are you initiating sleep, with "echo mem>/sys/power/state"? 

What does cat /sys/power/mem_sleep return?

Is /sys/power/sync_on_suspend set?

[Mnky313]

48 minutes ago, Ralphred said:

Hibernation needs a specific set-up to work properly.

How are you initiating sleep, with "echo mem>/sys/power/state"? 

What does cat /sys/power/mem_sleep return?

Is /sys/power/sync_on_suspend set?

I'm just hitting suspend from the power options in GNOME

initiating sleep using echo mem | sudo tee /sys/power/state has the same issue

mem_sleep returns 2 options: 's2idle' and 'deep'

No idea if /sys/power/sync_on_suspend is set but I just tried with setting it to 1 and same result.

[Ralphred]

43 minutes ago, Mnky313 said:

mem_sleep returns 2 options: 's2idle' and 'deep'

Is one of them in  brackets? like 

cat /sys/power/mem_sleep 
[s2idle] deep

if not set to s2idle with `echo s2idle>/sys/power/mem_sleep` and cat it again to see the "setting".

 

The kernel docs have the relationship between the names and states: Technically "suspend" would make a copy of memory on disk the same as hibernate (specified on the kernel command line /proc/cmdline with resume=[something] or in the .config as PM_STD_PARTITION) itself but only go into the hibernate state after being in a form of [suspend to ram|s2idle|standby] for a set period (my laptop is an hour - one hour in standby then goes full hibernate). 

 

So, if you are missing the config for hibernate, then "suspend" may fail because of that, hence trying to do things at a very low level by just echoing "freeze" into /sys/power/state and try to recover from that.

If that works then move onto the hibernation set-up by setting a resume= on the kernel command line (depends on your bootloader as to where to do that) and making sure hibernation works alone with echo "disk">/sys/power/state.

 

If the drive is still playing up after that my next step would be to set the NVME driver to static instead of a module (if it isn't already, I've never done linux with disk drivers as loadable modules).

 

EDIT: from the kernel docs page 

Quote

In many cases, all peripheral buses lose power when entering S2RAM, so devices must be able to handle the transition back to the "on" state.

Found it interesting is all...

[Mnky313]

16 minutes ago, Ralphred said:

Is one of them in  brackets? like 

cat /sys/power/mem_sleep 
[s2idle] deep

if not set to s2idle with `echo s2idle>/sys/power/mem_sleep` and cat it again to see the "setting".

 

The kernel docs have the relationship between the names and states: Technically "suspend" would make a copy of memory on disk the same as hibernate (specified on the kernel command line /proc/cmdline with resume=[something] or in the .config as PM_STD_PARTITION) itself but only go into the hibernate state after being in a form of [suspend to ram|s2idle|standby] for a set period (my laptop is an hour - one hour in standby then goes full hibernate). 

 

So, if you are missing the config for hibernate, then "suspend" may fail because of that, hence trying to do things at a very low level by just echoing "freeze" into /sys/power/state and try to recover from that.

If that works then move onto the hibernation set-up by setting a resume= on the kernel command line (depends on your bootloader as to where to do that) and making sure hibernation works alone with echo "disk">/sys/power/state.

 

If the drive is still playing up after that my next step would be to set the NVME driver to static instead of a module (if it isn't already, I've never done linux with disk drivers as loadable modules).

 

EDIT: from the kernel docs page 

Found it interesting is all...

Yes, s2idle is in brackets by default. I've tried changing it to deep but it doesn't fix the issue.

I'll give those suggestions a try in a bit and see what happens.