Battery drain during sleep. System suspended before kernel suspends all tasks. Lenovo ThinkPad T460

Bug #1886920 reported by Richard Ebeling
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

The same as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825636.

kaihengfeng closed that one "Because there's no response from the original bug reporter." and asked to file a report for all devices affected, so here I am, duplicating the report.

On Ubuntu MATE 18.04, as well as after the update to 20.04, the battery drains about 1,25% per hour of sleep (if I just close the lid).

$ cat /sys/power/mem_sleep
s2idle [deep]

tlp was initially installed on my machine. However, this behaviour also occurs if I
$ sudo apt purge tlp acpi-call-dkms && sudo reboot now

also, it occurs when booting from a freshly made MATE 20.04 live usb stick, so TLP shouldn't be the culprit.

All the log files look in all relevant aspects similar to what was reported in the old report. I'm happy to provide log files from my machine, if any are necessary.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: richard 1511 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: MATE
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2018-07-12 (735 days ago)
InstallationMedia: Ubuntu-MATE 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 04f2:b52c Chicony Electronics Co., Ltd Integrated Camera
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Lsusb-t:
 /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
 /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
     |__ Port 10: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
     |__ Port 10: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
MachineType: LENOVO 20FMS03600
Package: linux (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-40-generic root=/dev/mapper/ubuntu--mate--vg-root ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-40-generic N/A
 linux-backports-modules-5.4.0-40-generic N/A
 linux-firmware 1.187.1
Tags: focal
Uname: Linux 5.4.0-40-generic x86_64
UpgradeStatus: Upgraded to focal on 2020-05-22 (55 days ago)
UserGroups: adm cdrom dialout dip docker lpadmin plugdev sambashare sudo tty uucp
_MarkForUpload: True
dmi.bios.date: 09/21/2018
dmi.bios.vendor: LENOVO
dmi.bios.version: R06ET64W (1.38 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20FMS03600
dmi.board.vendor: LENOVO
dmi.board.version: Not Defined
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrR06ET64W(1.38):bd09/21/2018:svnLENOVO:pn20FMS03600:pvrThinkPadT460:rvnLENOVO:rn20FMS03600:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T460
dmi.product.name: 20FMS03600
dmi.product.sku: LENOVO_MT_20FM_BU_Think_FM_ThinkPad T460
dmi.product.version: ThinkPad T460
dmi.sys.vendor: LENOVO

Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1886920

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Richard Ebeling (richardebeling) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected focal
description: updated
Revision history for this message
Richard Ebeling (richardebeling) wrote : CRDA.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : IwConfig.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : Lspci.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : Lspci-vt.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : Lsusb-v.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : ProcEnviron.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : ProcModules.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : PulseList.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : RfKill.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : UdevDb.txt

apport information

Revision history for this message
Richard Ebeling (richardebeling) wrote : WifiSyslog.txt

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Does /sys/power/mem_sleep default to s2idle?

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Please also run the following before sleep and see if it helps:
# echo 0 > /sys/power/pm_async

Revision history for this message
Richard Ebeling (richardebeling) wrote :

$ cat /sys/power/mem_sleep
s2idle [deep]

---

For testing /sys/power/pm_async set to 0, I did:

$ cat /sys/class/power_supply/BAT1/energy_now
8380000
$ cat /sys/class/power_supply/BAT0/energy_now
20460000
$ date
Sa 18. Jul 13:21:18 CEST 2020
$ echo 0 | sudo tee /sys/power/pm_async
0
$ # suspended here
$ date
Sa 18. Jul 16:07:03 CEST 2020
$ cat /sys/class/power_supply/BAT0/energy_now
20460000
$ cat /sys/class/power_supply/BAT1/energy_now
6730000

so it still drains 1,25% of the total battery capacity per hour, just as with pm_async set to 1. Also, /var/log/syslog looks just as described in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1825636:

```
systemd[1]: Reached target Sleep.
systemd[1]: Starting Suspend...
systemd-sleep[179378]: Suspending system...
kernel: [107977.533865] PM: suspend entry (deep)

// suspended here (in this test for about 40 minutes)

kernel: [107977.556748] Filesystems sync: 0.022 seconds
kernel: [107977.558222] Freezing user space processes ... (elapsed 0.003 seconds) done.
kernel: [107977.561528] OOM killer disabled.
kernel: [107977.561529] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
kernel: [107977.563110] printk: Suspending console(s) (use no_console_suspend to debug)
kernel: [107977.600338] wlp4s0: deauthenticating from 24:65:11:8e:43:e5 by local choice (Reason: 3=DEAUTH_LEAVING)
kernel: [107977.839517] sd 1:0:0:0: [sda] Synchronizing SCSI cache
kernel: [107977.842556] sd 1:0:0:0: [sda] Stopping disk
kernel: [107978.011721] e1000e: EEE TX LPI TIMER: 00000011
kernel: [107979.463353] ACPI: EC: interrupt blocked
kernel: [107979.464153] ACPI: Preparing to enter system sleep state S3
kernel: [107979.470324] ACPI: EC: event blocked
kernel: [107979.470326] ACPI: EC: EC stopped
kernel: [107979.470327] PM: Saving platform NVS memory
kernel: [107979.470333] Disabling non-boot CPUs ...
kernel: [107979.471057] IRQ 128: no longer affine to CPU1
kernel: [107979.472083] smpboot: CPU 1 is now offline
kernel: [107979.476463] smpboot: CPU 2 is now offline
kernel: [107979.480230] IRQ 16: no longer affine to CPU3
kernel: [107979.480244] IRQ 130: no longer affine to CPU3
kernel: [107979.481273] smpboot: CPU 3 is now offline
kernel: [107979.486687] ACPI: Low-level resume complete
kernel: [107979.486918] ACPI: EC: EC started
kernel: [107979.486921] PM: Restoring platform NVS memory
kernel: [107979.497888] Enabling non-boot CPUs ...
kernel: [107979.498062] x86: Booting SMP configuration:
kernel: [107979.498067] smpboot: Booting Node 0 Processor 1 APIC 0x2
kernel: [107979.510701] CPU1 is up
kernel: [107979.510831] smpboot: Booting Node 0 Processor 2 APIC 0x1
kernel: [107979.514667] CPU2 is up
kernel: [107979.514807] smpboot: Booting Node 0 Processor 3 APIC 0x3
kernel: [107979.518519] CPU3 is up
kernel: [107979.525254] ACPI: Waking up from system sleep state S3
kernel: [107979.554696] ACPI: EC: interrupt unblocked
kernel: [107979.775701] ACPI: EC: event unblocked
kernel: [107980.356933] sd 1:0:0:0: [sda] Starting disk
```

description: updated
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Is it possible to disable Management Engine from BIOS?

AFAIK Linux ME driver is fallible during system suspend.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Can you attach dmesg right after boot?

Apparently the USB Bluetooth isn't working right.

Revision history for this message
Richard Ebeling (richardebeling) wrote :

It is not possible to disable the Intel ME from the BIOS set up.

I attached the result of running
$ dmesg > dmesg.log
after booting

I rarely use bluetooth, so I keep it disabled. To automatically disable it after boot, I use rfkill in the rc.local file:
```
$ cat /etc/rc.local
#!/bin/bash

sleep 10
rfkill block bluetooth
exit 0
```
that might explain what you found about it not working right? After clicking "Turn Bluetooth On" in the blueman-applet, I can connect to bluetooth speakers and play music.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

[ 33.395006] Bluetooth: hci0: command 0x0c03 tx timeout
[ 34.316133] usb 1-7: USB disconnect, device number 2
[ 34.316302] Bluetooth: hci0: HCI reset during shutdown failed

Can you please try blacklisting "btusb" instead of the custom script?

Revision history for this message
Richard Ebeling (richardebeling) wrote :

I commented out the three lines in /etc/rc.local and did the following:

$ echo "blacklist btusb" | sudo tee /etc/modprobe.d/blacklist-btusb.conf
$ sudo update-initramfs -u
$ sudo reboot now

output of dmesg does not contain "Bluetooth" (case sensitive) anymore and `lsmod | grep bt` gives no results.

The battery consumption while sleeping is still the same. Syslog unchanged.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Nothing suspicious, really. And the system seems to be too old to support pmc_core, so we can't check the SoC state easily.

Please install latest mainline kernel:
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8-rc7/

Then boot with kernel parameter "dyndbg='file drivers/pci/* +p; file drivers/usb/* +p' log_buf_len=16M", do a S3, then attach dmesg.

Revision history for this message
Richard Ebeling (richardebeling) wrote :

Since some time passed, I took the freedom to use the up-to-date mainline kernel as of today (5.9-rc1) instead of 5.8-rc7

xhci_hcd printing "//Ding dong!" had me smiling.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

[ 104.894933] i801_smbus 0000:00:1f.4: PCI PM: Suspend power state: D0

Can you please attach acpidump?

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Note to myself to I don't need to re-read the source again: basically acpi_pm_device_sleep_state() finds the i801 controller's power state for S3 is D0. It should be D3 instead.

Revision history for this message
Richard Ebeling (richardebeling) wrote :

output file of
$ sudo acpidump -o acpidump.txt
attached.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :
Revision history for this message
Richard Ebeling (richardebeling) wrote :

1.28% battery drain per hour.

dmesg still says:
[ 5622.828022] i801_smbus 0000:00:1f.4: PCI PM: Suspend power state: D0

Revision history for this message
Richard Ebeling (richardebeling) wrote :

Never mind, booted the wrong kernel (5.4.0). Will measure again.

Revision history for this message
Richard Ebeling (richardebeling) wrote :

Alright, here is the dmesg output for the rc1+ kernel. It still says power state D0 instead of D3 (Hope I didn't mess up anything this time):

[ 65.241409] i801_smbus 0000:00:1f.4: PCI PM: Suspend power state: D0

I did a quick test (about 30 minutes) on battery consumption yesterday, which also resulted in about 1.3% drain per hour. I will try to do a more serious test, but I don't know yet when I'll get to that.

Revision history for this message
Richard Ebeling (richardebeling) wrote :

I just had the opportunity to measure a longer sleep with the rc1+ kernel. The battery drain is still as high as before.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

I was wrong, D0 is the correct state for the device, which doesn't have PM capability.

Can you please install powertop and see the Package C-State count after S3?
In addition to that, would it be possible to see how Windows behaves?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.