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
    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
    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-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 
# cat /sys/class/power_supply/BAT1/status 

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.


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!

| improve this answer | |
  • Actually I found that workaround by accident for a good while now (noticed that the machine not sluggish, saw that it's not throttled any more and eventually figured it out). I didn't want to come up with it so it won't decrease the need for a real solution, but that's how I live every morning now: I unplug and plugin. Plus if the laptop goes into deeper sleep state, you'll need to repeat it. – Csaba Toth Mar 29 '19 at 19:31
  • Thanks for your tips about the GPU, I'll try that. If something I'm interested in undervolting / underclocking, because I'm not gaming much. And when I'd use it as GPGPU, I'll see how the cooling fares. I haven't looked at Phoronix forums, but we can load off the conversation to there. If there's no owner forum for this machine yet I'll create one. – Csaba Toth Mar 29 '19 at 19:33
  • That would be good. Let me know when you open the owner forum. – quad cricket Mar 30 '19 at 21:05
  • Here is this one: phoronix.com/forums/forum/software/linux-gaming/… – Csaba Toth Apr 1 '19 at 19:52
  • I had an ASUS GL702ZC before and I would not recommend it any more unfortunately: phoronix.com/forums/forum/hardware/general-hardware/… – Csaba Toth Apr 1 '19 at 19:53

My workaround for not charging for helios 500 and manjaro:

Linux XXX 5.2.0-1-MANJARO #1 SMP PREEMPT Sat Jun 22 23:22:07 UTC 2019 x86_64 GNU/Linux
  1. Turn on laptop without plugged in AC adapter
  2. login
  3. Connect AC adapter
  4. execute these commands:

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.

| improve this answer | |
  • 1
    Manjaro is off-topic here. Unless this is applicable to Ubuntu - I don't think so - I suggest editing and removing the reference to Majaro. If it isn't applicable please delete. – user880592 Jul 7 '19 at 23:22
  • 1
    I don't care if Manjaro is off-topic, thanks for your answer @pawel-czmok . Is your Helios 500 AMD or Intel based? On my machine the power_dpm_force_performance_level is in the /sys/devices/pci0000:00/0000:00:03.1/0000:07:00.0/0000:08:00.0/0000:09:00.0 directory. I'll dig for the other files. – Csaba Toth Sep 26 '19 at 19:32
  • I'm on 5.2.0-2 kernel, maybe that matters. The pp_dpm_sclk and pp_dpm_mclk files are in the same directory as the power_dpm_force_performance_level. These are GPU frequencies or some base CPU frequency? – Csaba Toth Sep 26 '19 at 19:37

Based on Pawel Czmock's answer working solution for Ubuntu 18.04 is:

  • List available frequencies (pp_dpm_sclk). For that, execute as sudo:

    cd '/sys/devices/pci0000:00'
    DPM_SCLK=$(find . -name 'pp_dpm_sclk')
    echo 'Available SCLK frequencies:'
    cat "$DPM_SCLK"

    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:

    if [ -n "$1" ]; then
    # Set manual level:
    DPM_LEVEL=$(find "$ROOT" -name 'power_dpm_force_performance_level')
    echo "Setting 'manual' level in $DPM_LEVEL"
    echo 'manual' > "$DPM_LEVEL"
    # Find frequency selector id:
    DPM_SCLK=$(find "$ROOT" -name 'pp_dpm_sclk')
    SCLK_VALUE=$(grep "$FREQUENCY" "$DPM_SCLK" | cut -d: -f1)
    if [ -z "$SCLK_VALUE" ]; then
        echo "$FREQUENCY not found in $DPM_SCLK"
        exit 1
    # Set frequency
    echo "Setting $FREQUENCY using id $SCLK_VALUE in $DPM_SCLK"
    echo "$SCLK_VALUE" > "$DPM_SCLK"
    # pp_dpm_mclk should get set automatically after pp_dpm_sclk is set

    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.

| improve this answer | |
  • Gotcha, basically this kinda does what @pawel-czmok said below, but finds the files for us. Does this affect the CPU though, or just the GPU? – Csaba Toth Sep 26 '19 at 19:39
  • The charging LED changes! I'll test it more after hard shutdown and cold restart later. – Csaba Toth Sep 26 '19 at 19:44
  • @CsabaToth It affects both CPU and GPU - checked with lscpu | grep MHz and with conky. – Valentyn Sep 27 '19 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.