ACPI Error AE_NOT_FOUND GPE.PL6B

Support and Help
, ,
1

Kubuntu Version: 24.04.1 LTS

Desktop Environment : KDE Plasma

Problem Description:
After a week of trying, I got hibernation to work on my Kubuntu Noble system. The problem is that after waking from hibernation and using Sleep (suspend), the system starts chewing up lots of processor time and dmesg starts repeating an ACPI error thousands of times. It’s an ACPI BIOS error regarding ‘could not resolve symbol’. I’m not sure it’s just a BIOS problem because it only occurs after I do certain things in Noble. Whether or not it’s just BIOS, I need some way to address the problem in the near term so I can use hibernate and sleep–both of which are very helpful for my work.

Steps to Reproduce:

  1. Hibernate the system (sudo systemctl hibernate)
  2. Resume from hibernation
  3. Suspend the system (sleep)
  4. Resume from suspend
  5. Processor and fans start going into overdrive and the ACPI Error messages swamp dmesg.

Expected Behavior:
5. above would not occur.

Actual Behavior:
5. above does occur

Relevant System Information:
$ uname -a
Linux 6.8.0-51-generic #52-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec 5 13:09:44 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Mobo: ASUSTeK model: Z890 MAX GAMING WIFI7 v: Rev 1.xx
UEFI: American Megatrends v: 1005 (THIS IS THE BIOS)
date: 11/25/2024

Screenshots or Error Messages:

[ 7411.369041] ACPI BIOS Error (bug): Could not resolve symbol [\_GPE.PL6B.BPC], AE_NOT_FOUND (20230628/psargs-330)
[ 7411.369044] ACPI Error: Aborting method \_GPE.PL6B due to previous error (AE_NOT_FOUND) (20230628/psparse-529)
[ 7411.369046] ACPI Error: Aborting method \_GPE._L6B due to previous error (AE_NOT_FOUND) (20230628/psparse-529)
[ 7411.369048] ACPI Error: AE_NOT_FOUND, while evaluating GPE method [_L6B] (20230628/evgpe-511)

→

What I’ve Tried:

I tried putting the system to sleep again. It wakes itself up almost immediately and the problem does not disappear.

I installed acpid to see if restarting that might reset the system and eliminate the problem. It does not.

I’ve installed tlp in the hopes that it may help identify more specifically the source of the problem.

One thing that did make the problem disappear, once at least, is hibernating the system again. It wakes itself up almost immediately, but the error messages stop and the fan and processor are normal. However, re-hibernating every time I suspend is not ideal, if it even continuous to work.

I’ve considered disabling whatever device is problematic but am not sure how to identify that device or whether disabling it would have other adverse effects.

2

This is most likely a bug in your BIOS/UEFi ( and one of the many reasons why hibernate is not on in Ubuntu)…

Check if there is an update for your BIOS, if not, you could try to disable the offending IRQ with something like:

echo "disable" > /sys/firmware/acpi/interrupts/gpe6F
1 Like
3

@slowtrain55 Welcome to Ubuntu Discourse :slight_smile:

Thank you for using the provided template, it greatly assists those who want to help.

1 Like
4

Many thanks ogra for your reply–that could prove very helpful. Will try. One minor thing, I think I need to disable gpe6B. Wish I had some idea what the consequences of doing so will be, but I’ll find out.

It’s odd that, if the problem is in the BIOS only, Windows has no problem hibernating and doesn’t seem to throw a load of errors after hibernate and then sleep. Maybe they worked out some way around the problem–perhaps disabling gpe6B in advance :slight_smile:

5

slowtrain55 - Another thought

Is this a laptop system ?
Then consider updating DSDT (Differentiated Services Description Table)

< TJ-> ACPI == Advanced Configuration and Power Interface. It provides a way for the PC firmware (UEFI/BIOS) to declare to an Operating System how to control its platform-specific hardware. ACPI provides several in-firmware ‘tables’. One such is the Differentiated Services Description Table (DSDT). This actually contains executable code in a special ACPI ‘language’ which the OS has to execute. Rather like Java and its Virtual Machine. when the OS boots it calls a ‘method’ in the DSDT reporting its name _OSI(“Linux”) and the code in _OSI() should configure the hardware correctly… in your case the PC [perhaps] doesn’t recognise it so it will adopt fail-safe minimal defaults. HOWEVER… in almost 100% of cases the DSDT will declare various “Windows XXXX” versions for _OSI() so we can have Linux pretend to be the latest Windows versions with something like “acpi_osi=Windows 2012” on the kernel command line. So, we need to identify which ‘names’ that PC’s DSDT recognises. To that do terminal command:

sudo strings /sys/firmware/acpi/tables/DSDT | grep -i windows

and identify the latest Windows version listed. OK, 2 steps now. 1. Test. 2. If OK, Apply. To test, reboot the PC, hold down Shift to get the GRUB boot menu. highlight the default entry, press ‘E’ to edit it, navigate to the line starting “linux …” … and add to the end the string (including double-quotations) “acpi_osi=Windows 2013” - then press Ctrl+X or F10 immediately to boot with that change. [this is just a bit of text that Linux kernel uses to fool the motherboard into thinking the booting OS is actually Windows, which causes the motherboard to enable additional functionality for power control in most cases ] - Test the system, if it has improved, make that setting permanent by adding it to GRUB_CMDLINE_LINUX in /etc/default/grub . after it boots check the setting was used with “cat /proc/cmdline”

-might help-

6

Ogra: I ran into that problem again (on next sleep), I disabled gpe6B, and that seemed to do the trick. Thanks again!

Here’s hoping gpe6B isn’t connected to anything important–but considering that it is an unrecognized symbol and my system does fine unless I put it in some odd state with hibernate and sleep, it probably isn’t important.

7

Thanks bashing-om! The computer is a desktop PC. Is there some reason it needs to be a laptop for your suggestion to work?

I’ve previously traced the problem back to the DSDT table. There’s a function in there that uses _L6B as a level-triggered GPE handler. It checks if GPE.PL6B exists with: If (CondRefOf (_GPE.PL6B)) { PL6B () }. I guess that’s when it concludes it’s not in the namespace.

So do you think it would be worth a try to have linux pretend to be windows in this case?

8

slowtrain55 - well

I can not see how it could hurt to test and see.

-give it a shot-

1 Like
9

bashing-om: Tricking my system into using Windows 2022 for acpi seems to be working! I’ve hibernated and resumed once. There were no error messages and my cpu and fans did not start dealing with high load. I’ll need to continue to try through multiple hibernation cycles to see if it holds, but this is looking very good!

ogra: While disabling gpe6F does address the situation once, I continue to have problems sleeping and hibernating afterwards because the system wakes up immediately. I’d need to check if that’s the case if I disable gpe6F on a fresh boot, before I hibernate / sleep and cause problems. Still, if it continues to work through multiple hibernations, bashing-om’s solution seems more solid given that it seems to give linux more access to what Windows can access and I don’t have to ignore a perpetual errors.

1 Like
10

slowtrain55 ) Great -

Pleased I could point ya to a viable solution.
( but in fairness, I have dealt with this situation before)

Now If I only had a 10th of TJ’s smarts >

-OH boy then would I have a swelled head-

11

bashing-om: Yeah, that solution required seriously deep knowledge of operating systems and how they handle firmware. Pretty genius!

I’m now on resume from hibernation #2 and all is going well. I’ll call this the solution if I can make it to 3 hibernations.

Incidentally, another thing your solution has fixed: before, I would have to restart fancontrol whenever I resumed from either hibernation or sleep. Otherwise the fans would start spinning much too fast–evidently because fancontrol was no longer working. Now fancontrol just works.

12

bashing-om : Yup, I’ve been able to hibernate and resume my system three times without problems with the solution you suggested. So, I’m marking your ideas as the “Solution” above. Thanks so much for a very good fix!

I should also mention that previously when I ran sudo acpidump -b to get a look at the acpi code, I got multiple errors about problems in the acpi files. These are now gone as well. It really does seem that the problem here is that my bios only exposes full acpi functionality if it thinks the OS is Windows. So tricking it into thinking it is working with Windows solves my central problem and others besides.

13

bashing-om : One issue, though, with making the command line change permanent: in /etc/default/grub, the entire line is surrounded by double quotes. I think that adding your line with double quotes would be a problem. I’m going to first try acpi_osi=Windows\ 2022. There’s also "acpi_osi=Windows 2022" or perhaps ‘acpi_osi=Windows 2022’.

14

In grub’s config file one must escape those quotes too with " … " - silly little space -
like so:

GRUB_CMDLINE_LINUX=" \"acpi_osi=Windows 2022\""

-it ain’t what it is, in linux-

1 Like
15

Thanks bashing-om, that saved me a headache of trying multiple alternatives!

16

slowtrain55

Oh Gosh - I know that feeling so well :stuck_out_tongue:
(it is also one of the reasons I run with a separate /var partition)

1 Like
17

Just fyi: As of a couple small kernel upgrades ago (last couple weeks), acpi_osi=Windows 2022 prevents the ACPI error only some of the time. I might go one or two hibernation cycles followed by sleep before the non-stop looped errors show up and force me to restart the system. This wouldn’t be as big a deal if session management in KDE and Firefox worked as they should, but they not infrequently put windows in the wrong places or don’t open them at all. This can be a substantial time sink given that I use 9 desktops and fill each one with apps, open files, and dolphin windows. It’s unfortunate that the kernel upgrades seem to have hampered the ‘windows’ fix.

18

And, as of the latest kernel updates, everything is working again with the acpi_osi=Windows 2022 line added. The situation seems to change with kernel updates.

19

Above my skill level to know what might be - or not be - going on.
But, good that you are keeping up.

-change is not always for the better-

1 Like
20

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.