Arch Linux

driikolu

Member

Registered: 2016-10-21

Posts: 11

Trying to understand "ACPI No handler or method for GPE"

Hello,

First of all, I'll give you some context.
I made my last update Saturday and did a reboot just after it. My archlinux worked like before, no problem.
I also made a reboot Sunday, without any problem.

But today (Monday), I turned off my computer with the cmd poweroff.
I tried to turn it on again 2 hours later and it was stuck on the boot with a bunch of the following error :
ACPI Error: No handler or method for GPE XX, disabling event

By searching a bit I found a solution that I applied without understanding it, I just added pci=nommconf to my GRUB_CMDLINE.
My computer booted again.

I made an update, didn't try to reboot so far, but I want to understand how it this error happened and why this GRUB option "fixed" it.

Thanks in advance for your help

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 22,410

Re: Trying to understand "ACPI No handler or method for GPE"

Can you reproduce the fault when removing nommconf ? I find it more likely that something (good candidate, mesa update having to rebuild a bunch of shaders) lead to a delay in starting your graphical target you interpreted the last message you saw (that's likely still present now -- check your dmesg/journalctl -k) and mad a potentially corrective action, that isn't actually related to the issue at hand.

Assuming it was an actual intermittent problem, chances are your UEFI firmware was in a weird state (do you have parallel Windows installations/other OSs?)

Also sunday and saturday are somewhat irrelevant and useless pieces of information. What exactly changed between the failure and now? Look at actual package versions, post the pacman.log preceding the failure.

Last edited by V1del (2023-10-03 11:42:04)

driikolu

Member

Registered: 2016-10-21

Posts: 11

Re: Trying to understand "ACPI No handler or method for GPE"

After this post I made an update and tried to reboot.
The grub nommconf wasn't persistent, and it booted without problem.

I thought that the informations were relevant to say "I don't think that an update broke it".
But by re-checking pacman.log, in fact I was wrong in my timeline (sorry).

However I did a full update pacman -Syu on 24/09 (Lots of package, no compilation error, do you want the list ?). I made multiple reboot without problem until the 02/10
And here is the only thing I did between these 2 :

[2023-10-01T17:18:52-0400] [PACMAN] Running 'pacman -R flatpak xdg-desktop-portal'
[2023-10-01T17:18:52-0400] [ALPM] transaction started
[2023-10-01T17:18:53-0400] [ALPM] removed flatpak (1:1.15.4-1)
[2023-10-01T17:18:53-0400] [ALPM] removed xdg-desktop-portal (1.16.0-3)
[2023-10-01T17:18:53-0400] [ALPM] transaction completed
[2023-10-01T17:18:53-0400] [ALPM] running '30-systemd-daemon-reload.hook'...
[2023-10-01T17:18:54-0400] [ALPM] running '30-systemd-update.hook'...
[2023-10-01T17:18:54-0400] [ALPM] running 'dbus-reload.hook'...

Also, I do not have other OS installed.
So the firmware weird state seems an interesting lead.

My goal is really to understand what could cause it to avoid it next time

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 22,410

Re: Trying to understand "ACPI No handler or method for GPE"

Those are unlikely to be related. Assuming we only dealt with a failure to bring up the graphical target that one time, one thing that used to be a potentially common occurence is the system starting "toofast"™ and the graphics card not being ready. This should™ be fixed by the introduction of the kms hook in mkinitcpio.conf (assuming you merged/took that over) but might also have been broken again by the advent of the simpledrm device (which you could try disabling via the "initcall_blacklist=simpledrm_platform_driver_init" kernel parameter.

FWIW trying to guess what might've caused it without full logs of the incident and it not being reproducible  might be quite unfruitful. Check whether logs where produced (you have quite usable filter capabilities for timeframes/boots in the journal) that might indicate what exactly failed that one time.