Unsolved

1 Rookie

 • 

3 Posts

25

October 18th, 2025 10:18

SSD unusably slow after resume from S3 in linux

Hi, 

I use a laptitude 7300 which gets rarely power cycled.

the supported sleep modes in linux seem to be:

cat /sys/power/mem_sleep 
s2idle [deep]

so I use S3 - but something seems to be terribly wrong.

the NVME SDD before going to sleep shows following performance using "dd":

1048576000 bytes (1.0 GB, 1000 MiB) copied, 4 s, 252 MB/s

after resume (connected to power supply) it shows this:

(105 MB, 100 MiB) copied, 76 s, 1.4 MB/s

over a minute for 100MiB!!!

I checked the firmware with fwupdmgr with following result:
Devices with the latest available firmware version:
 • MZVLB256HAHQ-000L7
 • System Firmware

so my FW seems to be up to date.

The workaround for now is to disconnect the powersupply before resuming the laptop and then plug it back in after it resumed.

That restores the full speed of the SDD but isn't practical.
I tried the original 100W, 65W and USBC power supplies - all the same.
I also didn't find a command to switch the device to battery - otherwise it might be possible to

write a on-resume script which first switches the notebook to battery before resuming - but

thinking about it I guess by the time the on-resume script is executed it would be already too late...

My partner has the same device with an SATA HDD and it seems to have the same problem!

My guess is, that there is something wrong in the system firmware - since S3 also is NOT the default sleep state but only s2idle and S3 needs to be forced by a commandline parameter.

Any ideas how to make this device work under linux?

Some infos:

I am using  MX Linux, which is Debian based

OS: MX x86_64
Host: Latitude 7300 
Kernel: 6.1.0-40-amd64 

/etc/os-release:

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

cmdline: mem_sleep_default=deep

SDD: 

vendor: Samsung

model: MZVLB256HAHQ-000L7

3 Apprentice

 • 

1K Posts

October 18th, 2025 10:53

Hi

Currently using DEB 13, after removing Mint, so I am not necessarily gonna have a sensible solution....

Edit /etc/default/grub and modify the kernel command line:

text
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvme_core.default_ps_max_latency_us=5500"

Then update GRUB and reboot:

sudo update-grub
#################################

Identify your NVMe device (e.g., 0000:02:00.0) via:

lspci | grep -i nvme
  • Disable D3 cold:

  1. text
    echo 0 | sudo tee /sys/bus/pci/devices/0000:02:00.0/d3cold_allowed

You can add this line to a resume or systemd service script to ensure it applies after every boot.

##########################
3: Disable Intel P-State if CPU Is Throttling

If the CPU clock remains locked at the lowest frequency after resume, disable Intel P-State:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_pstate=disable"

Then run:

sudo update-grub && sudo reboot

This switches Linux back to the acpi-cpufreq scaling driver, which restores proper CPU frequency after resume.

Fix 4: Full Power Cycle or BIOS Update

Some older Latitude BIOS versions leave the drive stuck in a half-powered state across suspend cycles.
To clear this:

  1. Power off, disconnect AC, and remove the battery.

  2. Hold the power button for 30 seconds.

  3. Reconnect and boot normally.

Then ensure your BIOS and NVMe firmware are updated from Dell Support.

Recommended Combination for Dell Latitude 7300

For consistent behaviour:

text
nvme_core.default_ps_max_latency_us=5500 nvme.noacpi=1

These two parameters balance performance and power without breaking suspend/resume on Dell systems.

After applying, verify with:

cat /sys/module/nvme_core/parameters/default_ps_max_latency_us

In summary, the most effective fix for your Dell Latitude 7300’s unusably slow SSD after S3 sleep is to set nvme_core.default_ps_max_latency_us=5500 and optionally nvme.noacpi=1 in GRUB, followed by sudo update-grub and reboot.

#############
The obvious caveats apply....
Never believe anything you hear, and only half of what I write.
Perhaps print all the above out for ease of reference, and pictures of the screens before you modify owt.

1 Rookie

 • 

3 Posts

October 18th, 2025 14:58

@anne_droid​ 
Thanks for your answer!

to 1:

As far as I understand the parameter nvme_core.default_ps_max_latency_us=5500"

controls the switch between the power states PS0 to PS4 of the NVME SDD.

On my SDD it is (using smartctl):

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     7.02W       -        -    0  0  0  0        0       0
 1 +     6.30W       -        -    1  1  1  1        0       0
 2 +     3.50W       -        -    2  2  2  2        0       0
 3 -   0.0760W       -        -    3  3  3  3      210    1200
 4 -   0.0050W       -        -    4  4  4  4     2000    8000

what I can see with the nvme command is, that even when the SDD has this terrible performance, the power state switches between PS4 and PS0.

└─$ ./nvme_cur_power.sh
get-feature:0x02 (Power Management), Current value:0x00000004
 Workload Hint (WH): 0 - No Workload
 Power State   (PS): 4

└─$ ./nvme_cur_power.sh
get-feature:0x02 (Power Management), Current value:00000000
 Workload Hint (WH): 0 - No Workload
 Power State   (PS): 0

So it's not, that the power state is stuck in PS4 (and if I understand correctly, the grub parameter would "just" disable" PS4) but the SDD switches to PS0 according to the nvme command.

sudo nvme get-feature /dev/nvme0 --feature-id=0x02 --human-readable

to 2:

I checked and D3cold is activated.

I don't want to deactivate D3cold as that would mean high power consumption and render the whole purpose of the sleep state meaningless.

to 3:

not an issue. The powersave governor switches between the frequencies on demand - even after resume.

to 4: 

not the issue here I guess, since when I  do a resume on battery power everything works flawlessly..

1 Rookie

 • 

3 Posts

October 18th, 2025 15:04

PS: Is it possible to move a Discussion into another category?
In my opinion the problem is unrelated to linux but a laptitude firmware problem.
I heard that windows is not using S3 deep_sleep anymore. If that is correct, then one could argue it's a Linux problem - but just because the other OS doesn't use the feature and hence doesn't find the bug...

3 Apprentice

 • 

1K Posts

October 18th, 2025 19:42

Hi

I did warn you, so Sorry it was a shot in the dark.

No Events found!

Top