Bug 203035 - AC Adapter not recognized properly on Acer Predator Helios 500 PH517-61-R0GX - AMD Ryzen 7 2700
Summary: AC Adapter not recognized properly on Acer Predator Helios 500 PH517-61-R0GX ...
Status: NEW
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Other (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: acpi_power-other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-25 15:42 UTC by Justin
Modified: 2020-07-29 09:17 UTC (History)
11 users (show)

See Also:
Kernel Version: 5.0.2
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump (897.90 KB, text/plain)
2019-06-12 08:20 UTC, Christian Hawkins
Details
journalctl -xb | grep ACPI output kernel 5.4 (15.29 KB, text/plain)
2019-12-14 18:47 UTC, Derek J. Clark
Details
attachment-7455-0.html (2.62 KB, text/html)
2020-01-26 11:25 UTC, leo60228
Details

Description Justin 2019-03-25 15:42:11 UTC
On the Acer Predator Helios 500 PH517-61-R0GX notebook the AC adapter is not being recognized as plugged in and the entire system will only perform as if it is on battery. 

Device: /org/freedesktop/UPower/devices/line_power_ACAD

I found this post online while looking for a solution verifying that I am not the only person with this issue:

 https://askubuntu.com/questions/1122662/how-can-i-make-upower-and-the-power-subsystem-recognize-that-the-power-supply-is

Currently tested on several different distributions including Artix and Manjaro (with a 5+ kernel) and Ubuntu 18.04.1

I also tried acpi_listen and it is showing nothing when plugging/unplugging the AC power connector. 

Since the AC connector is not being detected the system throttles down the CPU and GPU since it thinks it is on battery. This makes the laptop incredibly slow. My CPU cores are stuck idling at 548MHz and GPU capped at 149MHz.

I first noticed this when I was still running kernel 4.20.6 but for every kernel I have tried the results have been the same.
Comment 1 cstein12 2019-05-24 18:44:27 UTC
I can confirm that I have this exact same issue and it does not matter which linux distribution I run. Same exact laptop. My most recent kernel on Arco Linux was 5.1.9.
Comment 2 Thanathan 2019-05-24 23:05:38 UTC
I can confirm the issue too. It occurs on kernel-version >=4.19.1.

Using kernel 4.18.9 from the Arch Linux package archive the problem doesn't seem to occur. Any version greater than this reproduces the issue.


Additional (previous) observations: 

While testing different distributions, I noticed that the problem doesn't occur in Debian Stretch stable (Kernel 4.9). The error reappeared after using testing (4.19) in order to get missing firmware. It occured while installing the Debian package 'firmware-amd-graphics' after an initramfs-rebuild and a restart - after uninstalling, rebuilding and restarting the AC adapter was recognized again. Removing the package however is no viable solution due to the resulting lack of a gui.

In Arch Linux there is an AUR package called 'linux-predator' which builds kernel 4.17 and enables multimedia-keys. This leads to the system recognizing the AC-adapter but suffering random freezes.

Using a system with kernel >= 4.19 it recognizes the AC on some rare occasions until a restart.
Comment 3 Thanathan 2019-05-27 06:48:11 UTC
After a firmware update (Manjaro - linux-firmware 20190514.711d329-1) the the bug reocurred even on 4.18.9.
Additionally I lost gui/tui output shortly after the kernel was loaded, including ttys. Reverting to linux-firmware 20190424.4b and rebuilding initramfs fixed the issues.
Comment 4 cstein12 2019-05-27 18:39:04 UTC
not sure if i am allowed to do this on here, but being that the issue is related to this laptop directly I would like to link you guys to the bug report I have going on this thread for the suspend issue:
https://bugs.freedesktop.org/show_bug.cgi?id=110117
Comment 5 Christian Hawkins 2019-06-02 20:04:04 UTC
Maybe related:

My observation on Debian Buster and Ubuntu 19.04 is, that as long as the screen is not turned off (i.e. with xset dpms force off), performace is accepable. Once this happens, CPU goes down to 550MHz and Graphics card resides in the lowest power state.

Unplugging and plugging in power restores full CPU performance (surviving subsequent screen blankings), however GPU remains in slowest state.

Actions that trigger this bug:

* xset dpms force off
* display timeout in various desktop settings
* booting the device with DVI (booting with HDMI does not trigger the bug)

I am happy to help, but I don't know what logs to provide. Please instruct if you need any further details about this.
Comment 6 Christian Hawkins 2019-06-12 08:20:12 UTC
Created attachment 283215 [details]
acpidump

This is an acpidump of this system. I don't know if it helps, but I would like to supply as much (useful) info about this problem as possible.
Comment 7 cstein12 2019-06-12 18:29:41 UTC
(In reply to stein12c from comment #1)
> I can confirm that I have this exact same issue and it does not matter which
> linux distribution I run. Same exact laptop. My most recent kernel on Arco
> Linux was 5.1.9.

and by 5.1.9 i mean 5.1.4......
Comment 8 Christian Hawkins 2019-08-12 15:22:06 UTC
Issue still present in 5.2
Comment 9 Christian Hawkins 2019-10-08 12:52:09 UTC
Issue still present in 5.3
Comment 10 leo60228 2019-12-03 13:35:44 UTC
I've noticed that _BST sets the RCAP register, despite not otherwise touching the smart battery registers. Is it possible that this is confusing Linux? I don't have much experience with ACPI.
Comment 11 Derek J. Clark 2019-12-14 18:47:18 UTC
Created attachment 286293 [details]
journalctl -xb | grep ACPI output kernel 5.4
Comment 12 Derek J. Clark 2019-12-14 18:48:25 UTC
I believe the issue exists in the AMDGPU driver stack for this Vega10 GPU. When setting nomodeset as a kernel param in GRUB the AC device functions normally. This obviously disables the DM so it is not a feasible workaround. AC Power related ACPI events stop appearing after the GPU loads in the kernel, but detect fine during bootup.
Comment 13 Derek J. Clark 2019-12-22 23:40:46 UTC
Setting admgpu.dpm=0 as a kernel boot parameter allows for normal AC adapter and CPU function on this laptop. This is not a complete workaround as the GPU is forced into its lowest power state. Tested in Manjaro Linux Kernel 5.4.2 and Kernel 5.3.15. System would not boot under kernel 4.19.88.
Comment 14 velemas 2019-12-28 02:57:53 UTC
Yes, it is amdgpu related issue somehow. At first i thought it was the same as this bug https://bugs.freedesktop.org/show_bug.cgi?id=110777 and i described there the exact behavior with AC plugging and dpm=0. I also noticed in dmesg:

acer_wmi: Unknown function number - 8 - 0

when screen blanks due to inactivity.

Also blacklisting amdgpu module in kernel parameters (module_blacklist=amdgpu) leaves AC LED on but Xorg is unusable without this module.
Comment 15 leo60228 2020-01-06 17:05:47 UTC
amdgpu apparently always assumed the system was on AC power until https://github.com/torvalds/linux/commit/600ae890be59910e65b75fe25a1b900d83c0329c, which was introduced in 4.19. This seems like a likely candidate, but for some reason I'm now affected by this issue even when using Linux 4.17 and linux-firmware 2018-03-20...
Comment 16 leo60228 2020-01-06 17:06:26 UTC
The amdgpu.dpm=0 workaround works, so it isn't a hardware issue.
Comment 17 velemas 2020-01-06 18:50:07 UTC
(In reply to leo60228 from comment #15)
> amdgpu apparently always assumed the system was on AC power until
> https://github.com/torvalds/linux/commit/
> 600ae890be59910e65b75fe25a1b900d83c0329c, which was introduced in 4.19. This
> seems like a likely candidate, but for some reason I'm now affected by this
> issue even when using Linux 4.17 and linux-firmware 2018-03-20...

Some time ago I tried to build 5.4.6 with adev->pm.ac_power set to true unconditionally:

adev->pm.ac_power = true; // power_supply_is_system_supplied() > 0 ? true : false;

and

	//if (power_supply_is_system_supplied() > 0)
		adev->pm.ac_power = true;
	//else
	//	adev->pm.ac_power = false;

But in my case it did nothing.
Comment 18 Dave 2020-01-20 16:34:10 UTC
(In reply to Thanathan from comment #3)
> Additionally I lost gui/tui output shortly after the kernel was loaded,
> including ttys. Reverting to linux-firmware 20190424.4b and rebuilding
> initramfs fixed the issues.

I have found that I get similar hangs when the GPU is in the lowest clock / memory clock state, as well as the highest state.  Disabling these two states via: 

echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level
echo "2 3" > /sys/class/drm/card0/device/pp_dpm_mclk
echo "3 4 5 6" > /sys/class/drm/card0/device/pp_dpm_sclk

Allows the laptop to avoid these hangs with the updated firmware (though at a performance loss and higher idle power.)

I also noticed that these hangs are a reliable way to trigger the power issue, where the cord isn't recognized, as it persists after boot (sometimes for two or three boots before it is recognized again.)

Additionally, this problem only appears after boot - while waiting at the dmcrypt prompt, for instance, power is always detected normally.
Comment 19 Derek J. Clark 2020-01-26 02:00:35 UTC
(In reply to Dave from comment #18)
> (In reply to Thanathan from comment #3)
> > Additionally I lost gui/tui output shortly after the kernel was loaded,
> > including ttys. Reverting to linux-firmware 20190424.4b and rebuilding
> > initramfs fixed the issues.
> 
> I have found that I get similar hangs when the GPU is in the lowest clock /
> memory clock state, as well as the highest state.  Disabling these two
> states via: 
> 
> echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level
> echo "2 3" > /sys/class/drm/card0/device/pp_dpm_mclk
> echo "3 4 5 6" > /sys/class/drm/card0/device/pp_dpm_sclk
> 
> Allows the laptop to avoid these hangs with the updated firmware (though at
> a performance loss and higher idle power.)
> 
> I also noticed that these hangs are a reliable way to trigger the power
> issue, where the cord isn't recognized, as it persists after boot (sometimes
> for two or three boots before it is recognized again.)
> 
> Additionally, this problem only appears after boot - while waiting at the
> dmcrypt prompt, for instance, power is always detected normally.

Took your input and updated my workaround on github. Provides decent operation for now. 

https://github.com/pastaq/Acer-Ryzen-Helios-AC-Fix
Comment 20 leo60228 2020-01-26 11:25:46 UTC
Created attachment 286979 [details]
attachment-7455-0.html

Most of what I do is CPU-bound and my AC power jack is broken (the little
plastic ring is gone so the cord doesn't stay in), so I'm more concerned
about the battery status than GPU performance. I'm guessing that workaround
doesn't help with that? Either way, good job.

On Sat, Jan 25, 2020, 9:00 PM <bugzilla-daemon@bugzilla.kernel.org> wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=203035
>
> --- Comment #19 from Derek J. Clark (derekjohn.clark@gmail.com) ---
> (In reply to Dave from comment #18)
> > (In reply to Thanathan from comment #3)
> > > Additionally I lost gui/tui output shortly after the kernel was loaded,
> > > including ttys. Reverting to linux-firmware 20190424.4b and rebuilding
> > > initramfs fixed the issues.
> >
> > I have found that I get similar hangs when the GPU is in the lowest
> clock /
> > memory clock state, as well as the highest state.  Disabling these two
> > states via:
> >
> > echo "manual" >
> /sys/class/drm/card0/device/power_dpm_force_performance_level
> > echo "2 3" > /sys/class/drm/card0/device/pp_dpm_mclk
> > echo "3 4 5 6" > /sys/class/drm/card0/device/pp_dpm_sclk
> >
> > Allows the laptop to avoid these hangs with the updated firmware (though
> at
> > a performance loss and higher idle power.)
> >
> > I also noticed that these hangs are a reliable way to trigger the power
> > issue, where the cord isn't recognized, as it persists after boot
> (sometimes
> > for two or three boots before it is recognized again.)
> >
> > Additionally, this problem only appears after boot - while waiting at the
> > dmcrypt prompt, for instance, power is always detected normally.
>
> Took your input and updated my workaround on github. Provides decent
> operation
> for now.
>
> https://github.com/pastaq/Acer-Ryzen-Helios-AC-Fix
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 21 Derek J. Clark 2020-01-26 16:42:05 UTC
(In reply to leo60228 from comment #20)
> Created attachment 286979 [details]
> attachment-7455-0.html
> 
> Most of what I do is CPU-bound and my AC power jack is broken (the little
> plastic ring is gone so the cord doesn't stay in), so I'm more concerned
> about the battery status than GPU performance. I'm guessing that workaround
> doesn't help with that? Either way, good job.
> 
> On Sat, Jan 25, 2020, 9:00 PM <bugzilla-daemon@bugzilla.kernel.org> wrote:
> 
> > https://bugzilla.kernel.org/show_bug.cgi?id=203035
> >
> > --- Comment #19 from Derek J. Clark (derekjohn.clark@gmail.com) ---
> > (In reply to Dave from comment #18)
> > > (In reply to Thanathan from comment #3)
> > > > Additionally I lost gui/tui output shortly after the kernel was loaded,
> > > > including ttys. Reverting to linux-firmware 20190424.4b and rebuilding
> > > > initramfs fixed the issues.
> > >
> > > I have found that I get similar hangs when the GPU is in the lowest
> > clock /
> > > memory clock state, as well as the highest state.  Disabling these two
> > > states via:
> > >
> > > echo "manual" >
> > /sys/class/drm/card0/device/power_dpm_force_performance_level
> > > echo "2 3" > /sys/class/drm/card0/device/pp_dpm_mclk
> > > echo "3 4 5 6" > /sys/class/drm/card0/device/pp_dpm_sclk
> > >
> > > Allows the laptop to avoid these hangs with the updated firmware (though
> > at
> > > a performance loss and higher idle power.)
> > >
> > > I also noticed that these hangs are a reliable way to trigger the power
> > > issue, where the cord isn't recognized, as it persists after boot
> > (sometimes
> > > for two or three boots before it is recognized again.)
> > >
> > > Additionally, this problem only appears after boot - while waiting at the
> > > dmcrypt prompt, for instance, power is always detected normally.
> >
> > Took your input and updated my workaround on github. Provides decent
> > operation
> > for now.
> >
> > https://github.com/pastaq/Acer-Ryzen-Helios-AC-Fix
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.

It seems like the GPU power states disabled by the workaround are not handled by the drivers properly and it causes many power/performance related problems. The symptoms include lower GPU performance, CPU state stuck at 500Mhz, and lid closing causing the screen to have 100% distortion. This github workaround appears to solve all of these issues. However its not 100% stable and can still have some crashes. If you don't need (much) 3D acceleration and want the CPU to work as normal, admgpu.dpm=0 as a kernel boot parameter will allow the CPU to work as intended as it bypasses the buggy AMDGPU power state handling.
Comment 22 Alex Deucher 2020-02-13 16:47:48 UTC
Might be a similar issue to this:
https://bugzilla.kernel.org/show_bug.cgi?id=203733
Comment 23 Rémi Verschelde 2020-07-29 09:17:52 UTC
For the reference, there's a follow-up bug report over at DRM/amdgpu: https://gitlab.freedesktop.org/drm/amd/-/issues/999

Still no resolution though, the issue is still reproducible today with an up-to-date driver stack:

```
$ inxi -CSG -xx
System:    Host: helios Kernel: 5.7.9-desktop-1.mga8 x86_64 bits: 64 compiler: gcc v: 10.1.1 Desktop: KDE Plasma 5.19.3 
           tk: Qt 5.15.0 wm: kwin_x11 dm: SDDM Distro: Mageia 8 mga8 
CPU:       Topology: 8-Core model: AMD Ryzen 7 2700 bits: 64 type: MT MCP arch: Zen+ rev: 2 L2 cache: 4096 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 102207 
           Speed: 549 MHz min/max: 1550/3200 MHz Core speeds (MHz): 1: 549 2: 549 3: 550 4: 549 5: 549 6: 548 7: 549 8: 548 
           9: 548 10: 549 11: 549 12: 549 13: 548 14: 549 15: 549 16: 548 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] vendor: Acer Incorporated ALI 
           driver: amdgpu v: kernel bus ID: 09:00.0 chip ID: 1002:687f 
           Device-2: Quanta HD Webcam type: USB driver: uvcvideo bus ID: 1-7:2 chip ID: 0408:a060 
           Display: x11 server: Mageia X.org 1.20.8 compositor: kwin_x11 driver: amdgpu,v4l resolution: 1920x1080~144Hz 
           s-dpi: 96 
           OpenGL: renderer: AMD VEGA10 (DRM 3.37.0 5.7.9-desktop-1.mga8 LLVM 10.0.0) v: 4.6 Mesa 20.1.4 direct render: Yes
```

Note You need to log in before you can comment on or make changes to this bug.