3

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.

Csaba Toth
  • 1,498

3 Answers3

3

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.

Pawel Czmok
  • 31
3

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:

    FREQUENCY="1201Mhz"

if [ -n "$1" ]; then
    FREQUENCY="$1"
fi

ROOT='/sys/devices/pci0000:00'
# 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
fi

# 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.

zx485
  • 2,865
Valentyn
  • 131
  • 3
1

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!

quad cricket
  • 26