From: Armin Wolf <W_Armin@gmx.de>
To: rafael@kernel.org, lenb@kernel.org
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v3] ACPI: OSL: Poweroff when encountering a fatal ACPI error
Date: Wed, 4 Feb 2026 22:29:31 +0100 [thread overview]
Message-ID: <20260204212931.3860-1-W_Armin@gmx.de> (raw)
The ACPI spec states that the operating system should respond
to a fatal ACPI error by "performing a controlled OS shutdown in
a timely fashion". Comply with the ACPI specification by powering
off the system when ACPICA signals a fatal ACPI error. Users can
still disable this behavior by using the acpi.poweroff_on_fatal
kernel option to work around firmware bugs.
Link: https://uefi.org/specs/ACPI/6.6/19_ASL_Reference.html#fatal-fatal-error-check
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
---
Changes since v2:
- poweroff instead of triggering a kernel panic
Changes since v1:
- use IS_ENABLED() for checking the presence of CONFIG_ACPI_PANIC_ON_FATAL
---
.../admin-guide/kernel-parameters.txt | 9 +++++++++
drivers/acpi/Kconfig | 11 +++++++++++
drivers/acpi/osl.c | 19 ++++++++++++++++++-
3 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 1058f2a6d6a8..1f2eaa0ec424 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -187,6 +187,15 @@ Kernel parameters
unusable. The "log_buf_len" parameter may be useful
if you need to capture more output.
+ acpi.poweroff_on_fatal= [ACPI]
+ {0 | 1}
+ Causes the system to poweroff when the ACPI bytecode signals
+ a fatal error. The default value of this setting can
+ be configured using CONFIG_ACPI_POWEROFF_ON_FATAL.
+ Overriding this value should only be done for diagnosing
+ ACPI firmware problems, as the system might behave erratically
+ after having encountered a fatal ACPI error.
+
acpi_enforce_resources= [ACPI]
{ strict | lax | no }
Check for resource conflicts between native drivers
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index df0ff0764d0d..1610dd4c8278 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -65,6 +65,17 @@ config ACPI_THERMAL_LIB
depends on THERMAL
bool
+config ACPI_POWEROFF_ON_FATAL
+ bool "Poweroff on fatal ACPI error"
+ default y
+ help
+ The ACPI bytecode can signal that a fatal error has occurred using the Fatal()
+ ASL operator, normaly causing the system to poweroff. Disabling this option causes
+ such a condition to be treated like a ordinary ACPI error.
+
+ This setting can also be overridden during boot using the acpi.poweroff_on_fatal
+ kernel parameter.
+
config ACPI_DEBUGGER
bool "AML debugger interface"
select ACPI_DEBUG
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 05393a7315fe..f2b45fa4a752 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -11,8 +11,10 @@
#define pr_fmt(fmt) "ACPI: OSL: " fmt
+#include <linux/kconfig.h>
#include <linux/module.h>
#include <linux/kernel.h>
+#include <linux/reboot.h>
#include <linux/slab.h>
#include <linux/mm.h>
#include <linux/highmem.h>
@@ -70,6 +72,10 @@ static bool acpi_os_initialized;
unsigned int acpi_sci_irq = INVALID_ACPI_IRQ;
bool acpi_permanent_mmap = false;
+static bool poweroff_on_fatal = IS_ENABLED(CONFIG_ACPI_POWEROFF_ON_FATAL);
+module_param(poweroff_on_fatal, bool, 0);
+MODULE_PARM_DESC(poweroff_on_fatal, "Poweroff when encountering a fatal ACPI error");
+
/*
* This list of permanent mappings is for memory that may be accessed from
* interrupt context, where we can't do the ioremap().
@@ -1381,9 +1387,20 @@ acpi_status acpi_os_notify_command_complete(void)
acpi_status acpi_os_signal(u32 function, void *info)
{
+ struct acpi_signal_fatal_info *fatal_info;
+
switch (function) {
case ACPI_SIGNAL_FATAL:
- pr_err("Fatal opcode executed\n");
+ fatal_info = info;
+ pr_emerg("Fatal error while evaluating ACPI control method\n");
+ pr_emerg("Type 0x%X Code 0x%X Argument 0x%X\n",
+ fatal_info->type, fatal_info->code, fatal_info->argument);
+
+ if (poweroff_on_fatal)
+ orderly_poweroff(true);
+ else
+ add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
+
break;
case ACPI_SIGNAL_BREAKPOINT:
/*
--
2.39.5
next reply other threads:[~2026-02-04 21:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 21:29 Armin Wolf [this message]
2026-02-24 23:05 ` Armin Wolf
2026-02-25 21:28 ` Rafael J. Wysocki
2026-02-26 6:35 ` Armin Wolf
2026-02-26 18:46 ` Rafael J. Wysocki
2026-02-27 19:50 ` Armin Wolf
2026-02-27 19:55 ` Armin Wolf
2026-02-27 20:39 ` Rafael J. Wysocki
2026-03-01 17:59 ` Armin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260204212931.3860-1-W_Armin@gmx.de \
--to=w_armin@gmx.de \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®