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.
Now 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.
My workaround for not charging for helios 500 and manjaro:
echo "manual" > /sys/devices/pci0000:00/0000:00:03.1/0000:06:00.0/0000:07:00.0/0000:08:00.0/power_dpm_force_performance_level
echo 6 > /sys/devices/pci0000:00/0000:00:03.1/0000:06:00.0/0000:07:00.0/0000:08:00.0/pp_dpm_sclk
echo 4 > /sys/devices/pci0000:00/0000:00:03.1/0000:06:00.0/0000:07:00.0/0000:08:00.0/pp_dpm_mclk
After these three commands the charging led start glowing and OS know that the AC adapter is plugged in.
I hope that will help someone.
Based on Pawel Czmock's answer working solution for Ubuntu 18.04 is:
List available frequencies (pp_dpm_sclk). For that, execute as sudo:
If you see 1201Mhz there, proceed to next section. If not, you can decide which frequency to use by yourself (based on output from above script) and pass it as argument to script below
Apply desired frequency setting (by default 1201Mhz or pass argument i.e. 1301Mhz)
Execute as sudo:
After execution of this script CPU, GPU start to work on normal frequencies and Ubuntu switches to 'On-AC' mode as well as power indicator switches on
NOTE: Sometimes the script above executes but does not set those values - Logging out and logging in helps in this situation.
I have the same laptop and the same issue. I have reached out to the ACPI kernel devs but there is no guessing if we will ever have proper ACPI support for our AC power. The "good" news is that I have at least found a work-around to allow us to use the higher perfomance our systems are capable of.
Here are some things to check and try:
If you boot and your CPU frequencies are stuck at ~500MHz try unplugging the AC adapter. Sometimes it takes more than one attempt. That should kick you on to battery mode power settings. I leave the CPU governor to "ondemand".
I really recommend amdgpu-utils: https://github.com/Ricks-Lab/amdgpu-utils You will have to add: "amdgpu.ppfeaturemask=0xffff7fff" to your GRUB_CMDLINE_LINUX_DEFAULT= line in your /etc/default/grub and generate the new config, reinstall grub, and then reboot, but once the kernel has that set you now have massive control over your Vega 56. (See we went with AMD for a reason! Yay open-source drivers!)
The hack I apply to get my GPU up to speed is by setting the P0 state to a higher clock (since it is forced there on "battery mode"). One of the utils is amdgpu-pac and it allows us to edit the P0 state. First, as root, run "amdgpu-pac --execute_pac" and tweak your settings in real time. (The fan will read zero, this is normal as our laptop doesn't use the stock fan.) The power cap is 120w, nothing we can do about that without a hacked BIOS. The 0: Sclk P-State should be changed to a higher Mhz and mV. BE CAREFUL! This is just like overclocking. We have limted amps to go around so we will not be able to just set it to P7: and move on. I tested 1201 Mhz and 875 mV and that seems to work for me. If you find a better combination that's stable let me know. I left Mclk alone except changing "Set Mask:" to "1,2,3" so it cannot use the 0 state. I tried changing the 0: state and it locked everything up. Leave "Power Performance Mode" to AUTO, I noticed no difference changing it. Hitting save will apply it immediately. I use Unigine's heaven benchmark to stress test things (current score: 1761 on extreme"). Once you have settings you like jot them down, restart amdgpu-pac without arguments and set the settings, now when you hit save it will genereate a pac_writer_$$$$$.sh for you to run whenever you want to set the GPU to performance mode. It also helps to generate a reset.sh with the stock settings if you want to go back to saving power. That's about it.
Using these tricks I am able to (mostly) run this laptop at full perfomance under Linux. With any luck the ACPI devs will hear our cries and the future Linux kernels will simply detect our AC apdapter. Good luck!