I'm using Xfce4, and it has the
xfce4-power-manager for visual cues and
upower as one of the core support packages (and I see an
/usr/lib/upower/upowerd running in
ps aux output). Besides that there's also
pm-utils installed, and in the logs I see it's active. I'm not sure if that can stir any water, I definitely list it here for completeness.
The machine is an Acer Predator Helios 500 PH517-61-R0GX (AMD Ryzen). The exact same installation (literally the same SSD stick) was in an ASUS ROG Strix GL702ZC (also an AMD Ryzen laptop but with a Ryzen 1700 instead of a Ryzen 2700). I didn't have this type of problem with the ASUS.
# upower -d Device: /org/freedesktop/UPower/devices/line_power_ACAD native-path: ACAD power supply: yes updated: Sat 02 Mar 2019 10:08:52 PM PST (2442 seconds ago) has history: no has statistics: no line-power online: no Device: /org/freedesktop/UPower/devices/battery_BAT1 native-path: BAT1 vendor: PANASONIC model: AP17C5P serial: 1409 power supply: yes updated: Sat 02 Mar 2019 10:49:28 PM PST (6 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging energy: 73.1346 Wh energy-empty: 0 Wh energy-full: 74.074 Wh energy-full-design: 74.074 Wh energy-rate: 0 W voltage: 17.374 V percentage: 98% capacity: 100% technology: lithium-ion Daemon: daemon-version: 0.9.23 can-suspend: yes can-hibernate: no on-battery: yes on-low-battery: no lid-is-closed: no lid-is-present: yes is-docked: yes
Notice above the power supply
online: no and the batter
state: discharge, although as I'm writing this the situation is the opposite: the AC adapter is plugged in and the battery should be fully charged. That's also the practice, since if the battery was really discharging, I'd be out of power in about 1.5 hours.
UPower may get its info from the subsystems. I see this:
# cat /sys/class/power_supply/ACAD/online 0 # cat /sys/class/power_supply/BAT1/status Discharging
Even if I try to enforce the CPU frequency governor to be
performance, the CPUs are muffled:
# cat /proc/cpuinfo | grep MHz cpu MHz : 548.695 cpu MHz : 548.572 cpu MHz : 548.638 cpu MHz : 548.658 cpu MHz : 548.226 cpu MHz : 548.899 cpu MHz : 548.528 cpu MHz : 548.477 cpu MHz : 548.819 cpu MHz : 548.440 cpu MHz : 548.905 cpu MHz : 548.263 cpu MHz : 548.956 cpu MHz : 548.645 cpu MHz : 548.938 cpu MHz : 548.666
Actually this may not even be possible, because I thought the minimum is 1.5 GHz, but the system is surely sluggish sometimes.
I've tried to use
acpi_osi=Linux kernel boot parameter, but that doesn't seem to change the situation.
It's super interesting that in the
dmesg I see an interesting thing, it looks like that during early boot the ACPI subsystem detects that the AC adapter is indeed plugged in:
[ 0.882383] ACPI: AC Adapter [ACAD] (on-line) [ 0.882416] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 [ 0.882420] ACPI: Power Button [PWRB] [ 0.882446] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 [ 0.882449] ACPI: Sleep Button [SLPB] [ 0.882468] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input2 [ 0.882472] ACPI: Lid Switch [LID] [ 0.882491] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [ 0.882500] ACPI: Power Button [PWRF] [ 0.882552] ACPI: Video Device [DGPU] (multi-head: yes rom: no post: no) [ 0.882745] acpi device:2a: registered as cooling_device0
(complete dmesg: https://pastebin.com/x4QRbSCR)
I don't know when things turn around? What causes that boot-time proper on-line detection to screw up?
# uname -a Linux asus 4.20.13 #2 SMP Sat Mar 2 17:03:50 PST 2019 x86_64 GNU/Linux
I installed acpid (
apt install acpid). That didn't help with the situation in general, but I could run
acpi_listen and when I disconnect the AC adaptor, I see a bunch of messages. When I reconnect it's silence. The
/sys/class/power_supply/* readings above remain the same.