1 Rookie
•
9 Posts
2
64142
November 10th, 2020 02:00
XPS 13 9310, Ubuntu, deep sleep missing
My computer drains a lot of battery when in sleep mode.
I've tried following the steps outlined in this bug report, tried the diagnosis layed out in this question and disabled the "sign of life" options in the BIOS as described here.
I confirmed my system sleeps in the `s2idle` state. Which I suspect is the problem.
$ sudo journalctl | grep "PM: suspend" | tail -2 May 13 18:41:00 mex kernel: PM: suspend entry (s2idle) May 13 20:52:36 mex kernel: PM: suspend exit
However I have 2 issues when trying to follow the above guides: Firstly my `/sys/power/mem_sleep` file does not contain a `deep` option:
sudo cat /sys/power/mem_sleep [s2idle]
And secondly I can't seem to edit the file to add a `deep` option:
$ echo deep | sudo tee /sys/power/mem_sleep deep tee: /sys/power/mem_sleep: Invalid argument $ sudo sh -c 'echo deep > /sys/power/mem_sleep' sh: 1: echo: echo: I/O error
Not being able to close the lid and have the laptop suspend is very annoying. Any help on this would be greatly appreciated.
OS: Ubuntu 20.04, 5.8.0-26-generic / Hardware: Dell XPS 13 9310
matteli
1 Rookie
•
11 Posts
0
August 13th, 2023 11:00
I have the same issue (huge battery drain when suspended and no deep sleep mode available) on dell xps 13 9320, ubuntu 22.04, but my linux kernel is currently 6.2.0-26-generic. Any suggestions? should I change the kernel to 5.8? (none of the solutions I could find online so fare seems to work for my laptop)
(edited)
jrmlhermitte
1 Rookie
•
9 Posts
2
August 13th, 2023 18:05
Not having S3 (sleep to RAM) is quite a regression. What is the design reason to completely eliminate this feature without providing a suitable replacement? This will sadly have to be my last XPS. I have a MacBook I use daily and sometimes do not charge for days.
(edited)
matteli
1 Rookie
•
11 Posts
0
September 7th, 2024 11:22
It does not work on my XPS 13 9320.
I have this kernel
(edited)
jrmlhermitte
1 Rookie
•
9 Posts
1
September 12th, 2025 12:14
@DELL-Chris M Removing the S3 deep sleep option is unacceptable and egregious as it makes the laptop worthless. And I've used it for 3 years to confirm that.
The drain on my battery was so noticeable that I had to end up just shutting it down after every use (which makes having a laptop pointless). A few months later, I ended up buying a macbook air which could go with the lid closed and used occasionally for weeks. I understand they don't have this sleep mode anymore, but at least they are built around ensuring there is little battery drain.
What Dell did here was remove a feature from under the linux community with no proposed alternative.
I've had this laptop for 3 years and about to get a new one. It's going to be a $2k+ Lenovo Thinkpad. I'm only coming here to help possibly others realize what you're getting into if you're even thinking of getting a Dell. Don't suffer the 3 years that I have.
(edited)
matteli
1 Rookie
•
11 Posts
1
September 12th, 2025 12:26
100% agree @jrmlhermitte unfortunately. I am still using the XPS and have to shut it down each time to avoid having a depleted battery the next time I open it.
It's quite sad because otherwise I really like the Dell XPS 13 (so much that is my second one). However this battery drain issue alone makes it almost unworkable, and to other Linux users I can only recommend to avoid Dell XPS laptops.
(edited)
jrmlhermitte
1 Rookie
•
9 Posts
0
September 12th, 2025 12:38
Same. They've had years to think about this but chose not to support it openly here.
I'm on the latest Ubuntu images and the battery drain is still unacceptable so the claim that updating kernel version will address this is false. Also, I'm not going to use sleep then hibernate as it would require me to turn secure boot off (for hibernate).
I shut down my laptop as well as you say. And the problem is insidious as the laptop works and you only truly notice there's an issue after the return policy is over (otherwise I would have returned this immediately).
Dell should clearly be removed as a recommended option for Linux laptops on any forum unless they address this.
(edited)
jrmlhermitte
1 Rookie
•
9 Posts
0
September 15th, 2025 11:22
Just in case it might help others, I ran this test for 60 seconds:
```
turbostat --show Pkg%pc2,Pkg%pc3,Pkg%pc6,Pkg%pc7,Pkg%pc8,Pkg%pc9,Pk%pc10,SYS%LPI rtcwake -m freeze -s 60
```
and got:
```
Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 SYS%LPI
0.54 0.18 0.01 0.00 0.06 0.06 97.91 97.35
0.54 0.18 0.01 0.00 0.06 0.06 97.91 97.35
```
I don't understand fully yet, but the little I gather is that PC10 is the deepest sleep a processor can go into. When sleeping for 60s, it's there 97% of the time. When I run the test to about 30 min, I get 99.92% residency. Those seem like good numbers.
However, if I power off my laptop and leave it off (by closing the lid) for 8 hours, I see a 4% drain. So I can expect losing 12% battery a day. On a previous XPS, I would see maybe 1% drain max over a, and the battery was lower capacity. This is pretty unacceptable as this is well over a 10x degradation.
I will try to investigate why this is so and run a more thorough test measuring the residencies and follow up (might be a few weeks, very busy not much time to spend on this).
(edited)
jrmlhermitte
1 Rookie
•
9 Posts
0
September 19th, 2025 20:53
TL;DR: I tried having laptop sleep in airplan mode (no wifi no bluetooth). I saw a worse battery drain!
I let the laptop sleep again, this time putting it in airplane mode, and I went from 100% battery to 78% battery over `96404.903312` seconds (1.1 days). This is a 19.72% decrease in battery per day!
Relevant turbostat output:
```
# date;turbostat --show Pkg%pc2,Pkg%pc3,Pkg%pc6,Pkg%pc7,Pkg%pc8,Pkg%pc9,Pk%pc10,SYS%LPI echo freeze > /sys/power/state;date
Thu Sep 18 01:40:06 PM EDT 2025
[...]
96404.903312 sec
Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 SYS%LPI
0.00 0.00 0.00 0.00 0.00 0.00 99.84 (neg)
0.00 0.00 0.00 0.00 0.00 0.00 99.84 (neg)
Fri Sep 19 04:26:51 PM EDT 2025
```
Finally, I looked at logs to see if anything woke the machine up and it appears nothing did. Using the timestamps I got from the `date` commands (adding a second to the `until` timestamp since the logs are not inclusive on end timestamp), and only considering entries between "suspend entry" and "suspend exit" (i only see one suspend entry/exit over logs):
```
# journalctl --since="2025-09-18T13:40:06-04:00" --until="2025-09-19T16:26:52-04:00"
[...]
Sep 18 13:40:06 julien-XPS-13-9310 kernel: PM: suspend entry (s2idle)
Sep 18 13:40:06 julien-XPS-13-9310 kernel: Filesystems sync: 0.009 seconds
Sep 19 16:26:51 julien-XPS-13-9310 kernel: Freezing user space processes
Sep 19 16:26:51 julien-XPS-13-9310 kernel: Freezing user space processes completed (elapsed 0.003 seconds)
Sep 19 16:26:51 julien-XPS-13-9310 kernel: OOM killer disabled.
Sep 19 16:26:51 julien-XPS-13-9310 kernel: Freezing remaining freezable tasks
Sep 19 16:26:51 julien-XPS-13-9310 kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
Sep 19 16:26:51 julien-XPS-13-9310 kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Sep 19 16:26:51 julien-XPS-13-9310 kernel: ACPI: EC: interrupt blocked
Sep 19 16:26:51 julien-XPS-13-9310 kernel: ACPI: EC: interrupt unblocked
Sep 19 16:26:51 julien-XPS-13-9310 kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
Sep 19 16:26:51 julien-XPS-13-9310 kernel: OOM killer enabled.
Sep 19 16:26:51 julien-XPS-13-9310 kernel: Restarting tasks ...
Sep 19 16:26:51 julien-XPS-13-9310 kernel: mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: bound 0000:00:02.0 (ops i915_pxp_tee_component_ops [i915])
Sep 19 16:26:51 julien-XPS-13-9310 systemd-resolved[414]: Clock change detected. Flushing caches.
Sep 19 16:26:51 julien-XPS-13-9310 systemd-logind[1223]: Lid closed.
Sep 19 16:26:51 julien-XPS-13-9310 systemd-resolved[414]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server 100.100.100.100.
Sep 19 16:26:51 julien-XPS-13-9310 kernel: done.
Sep 19 16:26:51 julien-XPS-13-9310 kernel: random: crng reseeded on system resumption
Sep 19 16:26:51 julien-XPS-13-9310 systemd-resolved[414]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 100.100.100.100.
Sep 19 16:26:51 julien-XPS-13-9310 systemd-logind[1223]: Suspending...
Sep 19 16:26:51 julien-XPS-13-9310 kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Sep 19 16:26:51 julien-XPS-13-9310 systemd[54472]: Started snap.firmware-updater.firmware-notifier.service - Service for snap application firmware-updater.firmware-notifier.
Sep 19 16:26:51 julien-XPS-13-9310 systemd-logind[1223]: Lid opened.
Sep 19 16:26:51 julien-XPS-13-9310 NetworkManager[1303]: <info> [1758313611.1106] manager: sleep: sleep requested (sleeping: no enabled: yes)
Sep 19 16:26:51 julien-XPS-13-9310 ModemManager[1399]: <msg> [sleep-monitor-systemd] system is about to suspend
Sep 19 16:26:51 julien-XPS-13-9310 NetworkManager[1303]: <info> [1758313611.1109] device (wlp0s20f3): state change: unavailable -> unmanaged (reason 'unmanaged-sleeping', managed-typ>
Sep 19 16:26:51 julien-XPS-13-9310 NetworkManager[1303]: <info> [1758313611.1122] device (p2p-dev-wlp0s20f3): state change: unavailable -> unmanaged (reason 'unmanaged-sleeping', man>
Sep 19 16:26:51 julien-XPS-13-9310 NetworkManager[1303]: <info> [1758313611.1125] manager: NetworkManager state is now ASLEEP
Sep 19 16:26:51 julien-XPS-13-9310 kernel: PM: suspend exit
[...]
```
I don't see much going on here (other than the timestamps appearing to be incorrect; I'm guessing because writing logs is also frozen?). The laptop goes to sleep and then is woken up when it detects a lid open event.
I have exhausted what to try and I can only come to the conclusion that this laptop is just an expensive piece of garbage. My next purchase is going to have to be a macbook and certainly never again Dell.
Please do not advertise linux support for your XPS series laptops until you can allocate resources to your firmware team to reinstate S3 sleep. Otherwise this is fraudulent advertising. Dell has had at least 3 years to take action against this and decided to ignore this as can be evidenced by the dismissive accepted solution. As can be evidenced from my findings, this battery drain is not within reasonable use of a laptop. Letting is sit for 5 days lid closed without connection to power and expect to be able to open it and use it again would be deemed by the average person as a reasonable use a laptop. The solution is simple, reinstate S3 sleep or revoke the claim for linux support. Yet they choose to both claim linux support on Ubuntu and refuse to support S3 (or some other solution that would prevent battery drain), so yes, this is fraud ($1,500 worth of fraud in my case).
(edited)