Disabling GPE6 - GPE flooding prevention

A

archfan

Hi

I'm a FreeBSD beginner and having these strange ACPI errors whenever I boot into FreeBSD as seen below:

Excerpt from dmesg
Code: 
Jul 16 19:07:03 pliskin kernel: ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L6F] (20160527/evgpe-622)
Jul 16 19:07:03 pliskin kernel: ACPI Error: [PGRT] Namespace lookup failure, AE_NOT_FOUND (20160527/psargs-391)
Jul 16 19:07:03 pliskin kernel: ACPI Error: Method parse/execution failed [\_GPE._L6F] (Node 0xfffff800075cc740), AE_NOT_FOUND (20160527/psparse-559)
Jul 16 19:07:03 pliskin kernel: ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L6F] (20160527/evgpe-622)
Jul 16 19:07:03 pliskin kernel: ACPI Error: [PGRT] Namespace lookup failure, AE_NOT_FOUND (20160527/psargs-391)
Jul 16 19:07:03 pliskin kernel: ACPI Error: Method parse/execution failed [\_GPE._L6F] (Node 0xfffff800075cc740), AE_NOT_FOUND (20160527/psparse-559)
Jul 16 19:07:03 pliskin kernel: ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L6F] (20160527/evgpe-622)
Jul 16 19:07:03 pliskin kernel: ACPI Error: [PGRT] Namespace lookup failure, AE_NOT_FOUND (20160527/psargs-391)
Jul 16 19:07:03 pliskin kernel: ACPI Error: Method parse/execution failed [\_GPE._L6F] (Node 0xfffff800075cc740), AE_NOT_FOUND (20160527/psparse-559)
Jul 16 19:07:03 pliskin kernel: ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L6F] (20160527/evgpe-622)
Jul 16 19:07:03 pliskin kernel: ACPI Error: [PGRT] Namespace lookup failure, AE_NOT_FOUND (20160527/psargs-391)
Jul 16 19:07:03 pliskin kernel: ACPI Error: Method parse/execution failed [\_GPE._L6F] (Node 0xfffff800075cc740), AE_NOT_FOUND (20160527/psparse-559)
Jul 16 19:07:03 pliskin kernel: ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L6F] (20160527/evgpe-622)
Jul 16 19:07:03 pliskin kernel: ACPI Error: [PGRT] Namespace lookup failure, AE_NOT_FOUND (20160527/psargs-391)
Jul 16 19:07:03 pliskin kernel: ACPI Error: Method parse/execution failed [\_GPE._L6F] (Node 0xfffff800075cc740), AE_NOT_FOUND (20160527/psparse-559)
Jul 16 19:07:03 pliskin kernel: ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L6F] (20160527/evgpe-622)
Jul 16 19:07:03 pliskin kernel: ACPI Error: [PGRT] Namespace lookup failure, AE_NOT_FOUND (20160527/psargs-391)
Jul 16 19:07:03 pliskin kernel: ACPI Error: Method parse/execution failed [\_GPE._L6F] (Node 0xfffff800075cc740), AE_NOT_FOUND (20160527/psparse-559)

Is there a way to disable GPE6F specifically?

On Linux I would simply type echo "disable" > /sys/firmware/acpi/interrupts/gpe6 and the error would stop flooding my kernel logs.
 
With ACPI problems, your first step should generally be to check your BIOS version and update to the latest version from the vendor. It is not unusual for there to be ACPI bugs in the BIOS. Updating the BIOS is typically the best way to address that, if there is a newer version available.

If not, or the latest BIOS does not fix the problem, please tell us the vendor and model of your motherboard. Please also tell us the version of FreeBSD, and whether you are trying the i386 or amd64 build?
 
My motherboard is Asrock H170M-Pro4 with the latest BIOS version.

The FreeBSD version is 11-beta1 amd64. I've also tested 10 and it had the same errors.
 
Well, I did some Googling on this, and it looks almost certain that this is a bug in your BIOS. The workaround on FreeBSD is probably to override the BIOS ACPI DSDT, as https://bugzilla.kernel.org/show_bug.cgi?id=105491 points the finger at some bad vendor code in there. Really, this is something that the motherboard vendor should be fixing, as the blame appears to be theirs.

So, how to override the ACPI DSDT on FreeBSD. First, this is advanced stuff, with plenty of potential to go wrong. Second, official docs can be found at https://www.freebsd.org/doc/handbook/acpi-overview.html, acpidump(8), and iasl(8). Third, I am not an expert on ACPI stuff, I just know where to look and have some general knowledge about the problems that can exist with it.

The steps to patching your ACPI DSDT are:
  1. acpidump -dt > my.asl
  2. (optional) Edit my.asl to fix bugs.
  3. iasl -f my.asl
  4. Copy the compiled .aml file to /boot/acpi_dsdt.aml
  5. Add acpi_dsdt_load="YES" to /boot/loader.conf
  6. Reboot, verbose_loading="YES" and boot_verbose="YES" in /boot/loader.conf (or boot -v) recommended to give best visibility of what is going on.

Editing the .asl file is optional, as just recompiling the DSDT is sufficient for cases where the bug is in the compiler used by the vendor. Basically try just recompiling first, then move on to patching/editing the code itself if either recompiling fails or the problem is still there after trying the new DSDT. Search for "PGRT" and "_L6F" in the code to find the problematic section. Swearing at/about your motherboard vendor for having terrible QA and shipping a broken BIOS is common and acceptable throughout this process.

You should see something similar to the following early in your verbose boot output if the custom DSDT is being loaded:
Code: 
Preloaded acpi_dsdt "/boot/acpi_dsdt.aml" at 0xffffffff80ef27a0.
It appears between the initial copyright message and the CPU features list on 10.3.

Now, a caution about using 11.0. It is still at a very early stage of the release process and may have serious bugs. It is not yet really "stable", despite the creation of the stable/11 branch in SVN — that is an early step in changing it from being under active development to a properly stable release. I believe there's already a serious issue delaying release, and which might cause an ABI change (i.e. 11.0 BETA1 and 11.0 BETA2 may well be incompatible with each other). If you want stability, I recommend 10.3. If you are happy to deal with potentially serious bugs and possibly a rocky upgrade process, and want to participate in the beta, great go for it with 11.0. 11.0 should be stable in the not too distant future, it just isn't properly stable today.
 
Thanks for your help. I think I've located the buggy code that was responsible for this madness. Rebooted a couple of times and it seemed to have fixed the problem.

Code: 
  Name (PRES, One)
  Method (_L6F, 0, NotSerialized)  // _Lxx: Level-Triggered GPE
  {
  \_SB.UGPS ()
  If (RTD3 == One)
  {
  If (CondRefOf (\_GPE.AL6F))
  {
  AL6F ()
  }

Swearing at/about your motherboard vendor for having terrible QA and shipping a broken BIOS is common and acceptable throughout this process.
Click to expand...

:D
 
Dear archfan, I have facing same problem with such message flooding. Would you mind teach me how to fix it in order to install freebsd 10.3 on my new motherboard of asrock z170 pro4. Thanks a lot
 
Hi,

updating to the latest UEFI version (2.20 released on 7/20/2016) fixed this problem for me. Apparently 3.70 was released at the same time for your motherboard. It is likely that a simple UEFI update will fix this problem for you too.

Try this first before changing the ACPI tables.
 
Dear archfan,

You are right, I upgrade the BIOS to 3.7, all such messages did not appear again.

Thanks for your suggestion
 
You must log in or register to reply here.
Back
Top