Infinite loop on boot when loading ACPI

[Flaburgan]

The computer is an HP Pavilion 15-n059sf Notebook, core i3, 6GB of Ram, 1TB HDD dual boot with Windows 8.1.

On a fresh install of Linux Mint 18.2 64bits Cinnamon, the computer is taking a **very long time** to boot (3 hours 30 minutes!). See this forum to read details logs: https://forums.linuxmint.com/viewtopic.php?f=46&p=1381977&sid=a4c49df9a4cbcea6061f63f172617991

The problem is an ACPI error: output of dmesg:
[ 16.662017] Adding 6181884k swap on /dev/sda9. Priority:-1 extents:1 across:6181884k FS
[12596.103869] ACPI Error: Method parse/execution failed \AMD3._ON, AE_AML_INFINITE_LOOP (20170531/psparse-550)
[12596.103893] acpi device:02: Failed to change power state to D0

This problem is here with kernel 4.8 and higher (I even tried 4.14-rc6).
The problem is **not here** with kernel 4.4.

When editing the boot line, adding acpi=off, the problem is **not here** (tried with 4.13.10).

Thought disabling acpi does not seem like a good solution (fans are always turning, battery will be used very quickly).

I expect the computer to boot even if there is an ACPI error, not to be stuck in an infinite loop.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Eric Heintzmann (heintzmann-eric)]

The issue is still present on a 5.15 kernel.
On a HP Pavilion 17-0e50sf (Hybrid Graphics: Intel_i915/AMD_radeon ), the system hangs for about 40 seconds after the user login (tested with gdm, lightdm / GNOME, Weston, xfce / Xorg, Wayland).

dmesg output:

ACPI Error: Aborting method \AMD3._ON due to previous error (AE_AML_LOOP_TIMEOUT) (20210730/psparse-529)
acpi device:02: Failed to change power state to D0
[drm] PCIE gen 3 link speeds already enabled
[drm] PCIE GART of 2048M enabled (table at 0x0000000000040000).
radeon 0000:01:00.0: WB enabled
radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00
radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000040000c04
radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000040000c08
radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c
radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000040000c10
debugfs: File 'radeon_ring_gfx' in directory '1' already present!
debugfs: File 'radeon_ring_cp1' in directory '1' already present!
debugfs: File 'radeon_ring_cp2' in directory '1' already present!
debugfs: File 'radeon_ring_dma1' in directory '1' already present!
debugfs: File 'radeon_ring_dma2' in directory '1' already present!
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 1 succeeded in 1 usecs
[drm] ring test on 2 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 3 usecs
[drm] ring test on 4 succeeded in 3 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 1 succeeded in 0 usecs
[drm] ib test on ring 2 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] ib test on ring 4 succeeded in 0 usecs

Since the radeon is a South Island, I tried with both radeon and amdgpu kernel modules: same issue.

Also tried to call ACPI method \AMD3._ON with acpi_call module: it returns an error after 30 seconds.

Blacklisting the radeon and amdgpu modules allows me to work around the problem