Created attachment 144121 [details] gzipped acpidump output The Lenovo T440s ultrabook advertises a "powerbridge" facility. It has two batteries the second of which can be removed and replaced without power down. Power is automatically switched to be taken first battery. This all works fine on linux mint 16 except that when I remove the external battery I see an ACPI undock message in the logs: Jun 17 22:10:46 mintpad kernel: [14318.961979] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: undocking But when I replace the battery there is no docking message, no /sys/class/power_supply/BAT1 appears etc. Cinnamon applets reporting battery status started to get terribly confused about how much power is left. The only ways to force a re-detection are - hibernate/thaw, suspend/resume, shutdown/startup or plugging in the AC power. Ideally hot swap should allow avoiding the first three of these and if I had AC power to hand I would not need an additional battery. When I take one of these actions I do then see the message in the logs: Jun 17 22:20:35 mintpad kernel: [14575.691824] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: docking I'd love to find a fix or workaround for this bug. Any help appreciated. PS attached is the acpidump generated thus: michael@mintpad ~/Documents/linux/acpidump $ sudo acpidump > t440s_acpidump.txt [sudo] password for michael: Wrong checksum for FADT!
please attach the dmesg out after battery plugged and inserted.
There seems to be no log output in /var/log/dmesg at all either when the battery is removed or when reinserted. Syslog reports Sep 9 17:18:31 mintpad kernel: [40097.205424] ACPI: Device does not support D3cold Sep 9 17:18:31 mintpad kernel: [40097.205431] ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: undocking for undock and nothing for dock.
happy to try anything that might help diagnose...
please make sure your kernel is built with CONFIG_ACPI_DEBUG set, and then reboot with boot option "acpi.debug_layer=0x04 acpi.debug_level=0x08000004", please unplug the battery, and then plug it again, and attach the dmesg output.
ping...
Hi, I'm still here and still keen to get to the bottom of this and many thanks for your help thus far. Never built a kernel before so need to do a bit of research on that. Will get back to you as soon as I can Michael
Sorry been busy. I'm starting work on gathering the info today.
Information as requested. I compiled a later kernel 3.11.1 as I could not find a kernel 3.11.0-12 to download. I build and installed using the same config and set boot options and checked all was picked up: michael@mintpad ~ $ uname -r | tee ~michael/Documents/acpi.txt 3.11.1 michael@mintpad ~ $ uname -v | tee ~michael/Documents/acpi.txt #1 SMP Mon Jan 5 22:59:14 GMT 2015 michael@mintpad ~ $ cat /proc/cmdline | tee ~michael/Documents/acpi.txt BOOT_IMAGE=/boot/vmlinuz-3.11.1 root=UUID=0ad1ca87-adfa-4137-9354-416dd19d55c4 ro quiet splash acpi.debug_layer=0x04 acpi.debug_level=0x08000004 vt.handoff=7 Heres the known batteries before the test: michael@mintpad ~ $ ls /sys/class/power_supply/ AC BAT0 BAT1 I then undocked the battery and redocked a few seconds afterward. I noticed with 3.11.1 I do actually see an docked message now. But the battery state is still not correct so the message must be ignored: michael@mintpad ~ $ ls /sys/class/power_supply/ AC BAT0 There was no change do the dmesg content during the test but I believe the debug output you requested is in the syslog which I zipped and attached.
Created attachment 162671 [details] syslog after enabling acpi debug and performing 2nd battery undock and redock
I would add from further testing that the appearance of the ACPI docking message is not always guaranteed
I have made a discovery. With the original kernel version if I push one of the sliding catches or open an close and can guarantee the docking message and the battery present message. I think its dodgy hardware.
This was a hardware problem no software fix needed
*** Bug 117431 has been marked as a duplicate of this bug. ***