[SOLVED] ASUS X205T battery drain during suspend

[n_hologram]

Update: This computer died not long after the time of writing. As such, I cannot further test or give information about the issue.

It was a great irony to log in for the first time in over two years to see someone else posted an issue for this exact device.

Recently, I happened upon an ASUS X205T. It's an awful piece of equipment. Debian LXQt (stock ISO) is the most stable OS/DE combo out of like eight or nine other OSes I tried.

The only real issue I'm having is the battery drain during sleep states. You can close the lid/use a DE's suspend, and it'll drain the battery pretty substantially. Overnight it can drop from ~85% to ~35%. The nice tradeoff is the battery lasts like 10 hours while in use. But I've never seen a laptop with a *nix system drain this much while in a sleep state.

Suggestions are welcome.

Other honorable mentions:

While it's inactive, the green power light stays on, and it turns back on mad quick. For awhile, I wasn't even sure if it was suspending. So i tried a while sleep 2; do echo whatever; done loop to see if it kept looping while the screen was off. The loop doesn't run while the screen is blank, despite the power thing, so it seems like it's going into some sleep state.

Hibernate locks the system. Shutdown/charging is the "best" way not to lose power while inactive.

There's a great Debian article on the X205TA, but the hardware on those is a little different, it seems. Or I'm just missing something.

Code: Select all

$     inxi -Fxxxz
System:    Host: maui Kernel: 5.8.0-0.bpo.2-686 i686 bits: 32 compiler: N/A Desktop: LXQt 0.14.1 info: tint2 wm: Openbox 3.6.1 
           dm: SDDM Distro: Debian GNU/Linux 10 (buster) 
Machine:   Type: Laptop System: ASUSTeK product: X205TA v: 1.0 serial: <filter> 
           Mobo: ASUSTeK model: X205TA v: 1.0 serial: <filter> UEFI: American Megatrends v: X205TA.212 date: 09/04/2015 
Battery:   ID-1: BATC charge: 6.7 Wh condition: 30.3/38.0 Wh (80%) volts: 7.2/7.6 model: Intel SR 1 SR Real Battery 
           type: Li-ion serial: <filter> status: Discharging cycles: 271 
CPU:       Topology: Quad Core model: Intel Atom Z3735F bits: 64 type: MCP arch: Silvermont rev: 8 L2 cache: 1024 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 10666 
           Speed: 500 MHz min/max: 500/1833 MHz Core speeds (MHz): 1: 500 2: 500 3: 500 4: 500 
Graphics:  Device-1: Intel Atom Processor Z36xxx/Z37xxx Series Graphics & Display vendor: ASUSTeK driver: i915 v: kernel 
           bus ID: 00:02.0 chip ID: 8086:0f31 
           Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa resolution: 1366x768~60Hz 
           OpenGL: renderer: Mesa DRI Intel Bay Trail x86/MMX/SSE2 v: 4.2 Mesa 18.3.6 compat-v: 3.0 direct render: Yes 
Audio:     Device-1: Intel HDMI/DP LPE Audio driver: HdmiLpeAudio message: bus/chip ids unavailable 
           Device-2: chtrt5645 driver: chtrt5645 message: bus/chip ids unavailable 
           Sound Server: ALSA v: k5.8.0-0.bpo.2-686 
Network:   Message: No Device data found. 
           IF-ID-1: wlan0 state: up mac: <filter> 
Drives:    Local Storage: total: 29.12 GiB used: 12.03 GiB (41.3%) 
           ID-1: /dev/mmcblk1 model: MBG4GC size: 29.12 GiB serial: <filter> rev: 0x7 scheme: GPT 
Partition: ID-1: / size: 24.20 GiB used: 11.58 GiB (47.9%) fs: ext4 dev: /dev/mmcblk1p2 
           ID-2: swap-1 size: 4.11 GiB used: 455.8 MiB (10.8%) fs: swap dev: /dev/mmcblk1p3 
Sensors:   System Temperatures: cpu: 6280.4 C mobo: N/A 
           Fan Speeds (RPM): cpu: 0 
Info:      Processes: 181 Uptime: 1d 55m Memory: 1.86 GiB used: 727.8 MiB (38.2%) Init: systemd v: 241 runlevel: 5 Compilers: 
           gcc: 8.3.0 alt: 8 Shell: bash v: 5.0.3 running in: x-terminal-emul inxi: 3.0.32

[Head_on_a_Stick]

log in for the first time in over two years

Good to see you again

battery drain during sleep states

Check the content of /sys/power/mem_sleep — you probably have "s2idle" selected instead of "deep". If so (and if "deep" is shown as an available option) then try

Code: Select all

# echo deep > /sys/power/mem_sleep
# echo mem > /sys/power/state

If that helps with the battery consumption then add mem_sleep_default=deep as a kernel command line parameter (via /etc/default/grub).

Reference: https://www.kernel.org/doc/Documentatio ... states.txt

Hibernate locks the system

How do you know it's locked? Perhaps the display is just disabled. I would try the Intel DDX driver (xserver-xorg-video-intel) instead of X's built-in modesetting driver.

This X.Org configuration file will force the Intel DDX driver:

Code: Select all

Section "Device"
   Identifier "Intel Graphics"
   Driver "intel"
EndSection

[sgosnell]

Hibernate writes the entire RAM to disk, and it takes awhile to read it all back. Reviving from hibernation can take longer than a complete reboot, so I never use it. On my old Acer former chromebook, a reboot isn't much longer than a recovery from suspend.

[n_hologram]

Good to see you again

You as well ^_^

Check the content of /sys/power/mem_sleep — you probably have "s2idle" selected instead of "deep".

Yup, that's the only thing there.

If so (and if "deep" is shown as an available option) then try

Code: Select all

# echo deep > /sys/power/mem_sleep

Throws an error:

Code: Select all

bash: echo: write error: Invalid argument

...

Code: Select all

# echo mem > /sys/power/state

Leads to the same "hibernate locks the system" noted earlier.

BY THE WAY, "lock" may not have been the best word to describe the issue. Hibernate causes the system to freeze/become unresponsive/etc. So any feature that hibernates causes:

1) the screen to black out for a second or two
2) the screen to turn back on, but become totally unresponsive, and
3) that's pretty much it 'til a hard reboot is given.

I would try the Intel DDX driver (xserver-xorg-video-intel) instead of X's built-in modesetting driver.

This package was already installed.

...Reviving from hibernation...

See above. It's not even making it that far :\

[Head_on_a_Stick]

Check the content of /sys/power/mem_sleep — you probably have "s2idle" selected instead of "deep".

Yup, that's the only thing there.

That means that the "deep" suspend mode (suspend to RAM) is not available for that machine, which is why the battery drains so fast.

You could try the newer kernel (metapackage) from the buster-backports repository to see if support has been added there.

EDIT: no, I see you're already using that. Perhaps submit a bug report to the kernel developers then.

I would try the Intel DDX driver (xserver-xorg-video-intel) instead of X's built-in modesetting driver.

This package was already installed.

Yes but I think Debian buster defaults to the modesetting DDX driver for Intel hardware. Check the X.Org log to confirm this. My posted configuration file will force the Intel DDX driver instead.

And also try adding the Intel kernel driver (i915) to /etc/initramfs-tools/modules and then rebuild the initramfs to include it:

Code: Select all

# update-initramfs -u -k all

[n_hologram]

Sorry for the late followup, friend. That laptop ended up taking a massive dump. Got a new one with a Christmas bonus. Would it still be wise to report the bug, even though the system itself isn't working? (Intuition and laziness tells me no, but I'm open.)

[Head_on_a_Stick]

Would it still be wise to report the bug, even though the system itself isn't working?

Probably not, you have no way to provide any further information for them so I don't think it would be much use.

[n_hologram]

Yeah, I'm mentally and emotionally writing this one off as the possible result of hardware defects. Thanks for the help regardless.