Documentation/arch/x86/amd-debugging.rst | 42 ++++++++++++++++++- arch/x86/include/asm/amd/fch.h | 1 +- arch/x86/kernel/cpu/amd.c | 53 +++++++++++++++++++++++- 3 files changed, 96 insertions(+)
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: b343579de7b250101e4ed6c354b4c1fa986973a7
Gitweb: https://git.kernel.org/tip/b343579de7b250101e4ed6c354b4c1fa986973a7
Author: Yazen Ghannam <yazen.ghannam@amd.com>
AuthorDate: Tue, 22 Apr 2025 18:48:30 -05:00
Committer: Borislav Petkov (AMD) <bp@alien8.de>
CommitterDate: Fri, 02 May 2025 10:57:40 +02:00
x86/CPU/AMD: Print the reason for the last reset
The following register contains bits that indicate the cause for the
previous reset.
PMx000000C0 (FCH::PM::S5_RESET_STATUS)
This is useful for debug. The reasons for reset are broken into 6 high level
categories. Decode it by category and print during boot.
Specifics within a category are split off into debugging documentation.
The register is accessed indirectly through a "PM" port in the FCH. Use
MMIO access in order to avoid restrictions with legacy port access.
Use a late_initcall() to ensure that MMIO has been set up before trying to
access the register.
This register was introduced with AMD Family 17h, so avoid access on older
families. There is no CPUID feature bit for this register.
[ bp: Simplify the reason dumping loop. ]
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20250422234830.2840784-6-superm1@kernel.org
---
Documentation/arch/x86/amd-debugging.rst | 42 ++++++++++++++++++-
arch/x86/include/asm/amd/fch.h | 1 +-
arch/x86/kernel/cpu/amd.c | 53 +++++++++++++++++++++++-
3 files changed, 96 insertions(+)
diff --git a/Documentation/arch/x86/amd-debugging.rst b/Documentation/arch/x86/amd-debugging.rst
index d3290f2..dea8a91 100644
--- a/Documentation/arch/x86/amd-debugging.rst
+++ b/Documentation/arch/x86/amd-debugging.rst
@@ -318,3 +318,45 @@ As mentioned above, parsing by hand can be tedious, especially with a lot of
messages. To help with this, a tool has been created at
`amd-debug-tools <https://git.kernel.org/pub/scm/linux/kernel/git/superm1/amd-debug-tools.git/about/>`_
to help parse the messages.
+
+Random reboot issues
+====================
+When a random reboot occurs, the high-level reason for the reboot is stored
+in a register that will persist onto the next boot.
+
+There are 6 classes of reasons for the reboot:
+ * Software induced
+ * Power state transition
+ * Pin induced
+ * Hardware induced
+ * Remote reset
+ * Internal CPU event
+
+.. csv-table::
+ :header: "Bit", "Type", "Reason"
+ :align: left
+
+ "0", "Pin", "thermal pin BP_THERMTRIP_L was tripped"
+ "1", "Pin", "power button was pressed for 4 seconds"
+ "2", "Pin", "shutdown pin was shorted"
+ "4", "Remote", "remote ASF power off command was received"
+ "9", "Internal", "internal CPU thermal limit was tripped"
+ "16", "Pin", "system reset pin BP_SYS_RST_L was tripped"
+ "17", "Software", "software issued PCI reset"
+ "18", "Software", "software wrote 0x4 to reset control register 0xCF9"
+ "19", "Software", "software wrote 0x6 to reset control register 0xCF9"
+ "20", "Software", "software wrote 0xE to reset control register 0xCF9"
+ "21", "Sleep", "ACPI power state transition occurred"
+ "22", "Pin", "keyboard reset pin KB_RST_L was asserted"
+ "23", "Internal", "internal CPU shutdown event occurred"
+ "24", "Hardware", "system failed to boot before failed boot timer expired"
+ "25", "Hardware", "hardware watchdog timer expired"
+ "26", "Remote", "remote ASF reset command was received"
+ "27", "Internal", "an uncorrected error caused a data fabric sync flood event"
+ "29", "Internal", "FCH and MP1 failed warm reset handshake"
+ "30", "Internal", "a parity error occurred"
+ "31", "Internal", "a software sync flood event occurred"
+
+This information is read by the kernel at bootup and is saved into the
+kernel ring buffer. When a random reboot occurs this message can be helpful
+to determine the next component to debug such an issue.
diff --git a/arch/x86/include/asm/amd/fch.h b/arch/x86/include/asm/amd/fch.h
index 01ee15b..2cf5153 100644
--- a/arch/x86/include/asm/amd/fch.h
+++ b/arch/x86/include/asm/amd/fch.h
@@ -8,5 +8,6 @@
#define FCH_PM_DECODEEN 0x00
#define FCH_PM_DECODEEN_SMBUS0SEL GENMASK(20, 19)
#define FCH_PM_SCRATCH 0x80
+#define FCH_PM_S5_RESET_STATUS 0xC0
#endif /* _ASM_X86_AMD_FCH_H_ */
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 2b36379..9a8c590 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -9,6 +9,7 @@
#include <linux/sched/clock.h>
#include <linux/random.h>
#include <linux/topology.h>
+#include <asm/amd/fch.h>
#include <asm/processor.h>
#include <asm/apic.h>
#include <asm/cacheinfo.h>
@@ -1237,3 +1238,55 @@ void amd_check_microcode(void)
if (cpu_feature_enabled(X86_FEATURE_ZEN2))
on_each_cpu(zenbleed_check_cpu, NULL, 1);
}
+
+static const char * const s5_reset_reason_txt[] = {
+ [0] = "thermal pin BP_THERMTRIP_L was tripped",
+ [1] = "power button was pressed for 4 seconds",
+ [2] = "shutdown pin was shorted",
+ [4] = "remote ASF power off command was received",
+ [9] = "internal CPU thermal limit was tripped",
+ [16] = "system reset pin BP_SYS_RST_L was tripped",
+ [17] = "software issued PCI reset",
+ [18] = "software wrote 0x4 to reset control register 0xCF9",
+ [19] = "software wrote 0x6 to reset control register 0xCF9",
+ [20] = "software wrote 0xE to reset control register 0xCF9",
+ [21] = "ACPI power state transition occurred",
+ [22] = "keyboard reset pin KB_RST_L was asserted",
+ [23] = "internal CPU shutdown event occurred",
+ [24] = "system failed to boot before failed boot timer expired",
+ [25] = "hardware watchdog timer expired",
+ [26] = "remote ASF reset command was received",
+ [27] = "an uncorrected error caused a data fabric sync flood event",
+ [29] = "FCH and MP1 failed warm reset handshake",
+ [30] = "a parity error occurred",
+ [31] = "a software sync flood event occurred",
+};
+
+static __init int print_s5_reset_status_mmio(void)
+{
+ unsigned long value;
+ void __iomem *addr;
+ int i;
+
+ if (!cpu_feature_enabled(X86_FEATURE_ZEN))
+ return 0;
+
+ addr = ioremap(FCH_PM_BASE + FCH_PM_S5_RESET_STATUS, sizeof(value));
+ if (!addr)
+ return 0;
+
+ value = ioread32(addr);
+ iounmap(addr);
+
+ for (i = 0; i <= ARRAY_SIZE(s5_reset_reason_txt); i++) {
+ if (!(value & BIT(i)))
+ continue;
+
+ if (s5_reset_reason_txt[i])
+ pr_info("x86/amd: Previous system reset reason [0x%08lx]: %s\n",
+ value, s5_reset_reason_txt[i]);
+ }
+
+ return 0;
+}
+late_initcall(print_s5_reset_status_mmio);
* tip-bot2 for Yazen Ghannam <tip-bot2@linutronix.de> wrote:
> The register is accessed indirectly through a "PM" port in the FCH. Use
> MMIO access in order to avoid restrictions with legacy port access.
>
> Use a late_initcall() to ensure that MMIO has been set up before trying to
> access the register.
>
> This register was introduced with AMD Family 17h, so avoid access on older
> families. There is no CPUID feature bit for this register.
>
> [ bp: Simplify the reason dumping loop. ]
>
> Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
> Co-developed-by: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
> Link: https://lore.kernel.org/20250422234830.2840784-6-superm1@kernel.org
> ---
> Documentation/arch/x86/amd-debugging.rst | 42 ++++++++++++++++++-
> arch/x86/include/asm/amd/fch.h | 1 +-
> arch/x86/kernel/cpu/amd.c | 53 +++++++++++++++++++++++-
> 3 files changed, 96 insertions(+)
Looks mostly good, with a few minor comments:
> +Random reboot issues
> +====================
> +When a random reboot occurs, the high-level reason for the reboot is stored
> +in a register that will persist onto the next boot.
Please add an extra newline after the section title, as the rest of the
document does.
> +There are 6 classes of reasons for the reboot:
> + * Software induced
> + * Power state transition
> + * Pin induced
> + * Hardware induced
> + * Remote reset
> + * Internal CPU event
>
> +.. csv-table::
> + :header: "Bit", "Type", "Reason"
> + :align: left
> +
> + "0", "Pin", "thermal pin BP_THERMTRIP_L was tripped"
> + "1", "Pin", "power button was pressed for 4 seconds"
> + "2", "Pin", "shutdown pin was shorted"
> + "4", "Remote", "remote ASF power off command was received"
> + "9", "Internal", "internal CPU thermal limit was tripped"
> + "16", "Pin", "system reset pin BP_SYS_RST_L was tripped"
> + "17", "Software", "software issued PCI reset"
> + "18", "Software", "software wrote 0x4 to reset control register 0xCF9"
> + "19", "Software", "software wrote 0x6 to reset control register 0xCF9"
> + "20", "Software", "software wrote 0xE to reset control register 0xCF9"
> + "21", "Sleep", "ACPI power state transition occurred"
This line is a bit of an odd one out: all other classes are the first
word of their classes, while this one only says 'Sleep', that is
specific to the event. "ACPI-state" might be a better class I suspect.
> + "22", "Pin", "keyboard reset pin KB_RST_L was asserted"
> + "23", "Internal", "internal CPU shutdown event occurred"
> + "24", "Hardware", "system failed to boot before failed boot timer expired"
> + "25", "Hardware", "hardware watchdog timer expired"
> + "26", "Remote", "remote ASF reset command was received"
> + "27", "Internal", "an uncorrected error caused a data fabric sync flood event"
> + "29", "Internal", "FCH and MP1 failed warm reset handshake"
> + "30", "Internal", "a parity error occurred"
> + "31", "Internal", "a software sync flood event occurred"
> +
> +This information is read by the kernel at bootup and is saved into the
> +kernel ring buffer. When a random reboot occurs this message can be helpful
> +to determine the next component to debug such an issue.
The ring-buffer reference is a bit obtuse and confusing - printk is a
log buffer. Maybe this refers to some earlier version of the patch?
Also:
s/determine the next component to debug such an issue.
/determine the next component to debug.
How about:
This information is read by the kernel at bootup and printed into
the syslog. When a random reboot occurs this message can be helpful
to determine the next component to debug.
> + [16] = "system reset pin BP_SYS_RST_L was tripped",
s/tripped
/shorted
> + [22] = "keyboard reset pin KB_RST_L was asserted",
s/asserted
/shorted
'asserted' is fine too - but all 'pin' class messages should use
consistent wording.
> +static __init int print_s5_reset_status_mmio(void)
> +{
> + unsigned long value;
> + void __iomem *addr;
> + int i;
> +
> + if (!cpu_feature_enabled(X86_FEATURE_ZEN))
> + return 0;
> +
> + addr = ioremap(FCH_PM_BASE + FCH_PM_S5_RESET_STATUS, sizeof(value));
> + if (!addr)
> + return 0;
> +
> + value = ioread32(addr);
> + iounmap(addr);
> +
> + for (i = 0; i <= ARRAY_SIZE(s5_reset_reason_txt); i++) {
> + if (!(value & BIT(i)))
> + continue;
> +
> + if (s5_reset_reason_txt[i])
> + pr_info("x86/amd: Previous system reset reason [0x%08lx]: %s\n",
> + value, s5_reset_reason_txt[i]);
Please use curly braces around multi-line statements.
With those addressed:
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Thanks,
Ingo
* Ingo Molnar <mingo@kernel.org> wrote:
> With those addressed:
>
> Reviewed-by: Ingo Molnar <mingo@kernel.org>
Patch attached to clean this all up.
Thanks,
Ingo
====================>
From: Ingo Molnar <mingo@kernel.org>
Date: Sun, 4 May 2025 08:57:37 +0200
Subject: [PATCH] x86/CPU/AMD: Clean up the last-reset printing code a bit
- Use consistent .rst formatting
- Fix 'Sleep' class field to 'ACPI-State'
- Standardize pin messages around the 'tripped' verbiage
- Remove reference to ring-buffer printing & simplify
the wording
- Use curly braces for multi-line conditional statements
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Yazen Ghannam <yazen.ghannam@amd.com>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
---
Documentation/arch/x86/amd-debugging.rst | 18 ++++++++++++------
arch/x86/kernel/cpu/amd.c | 15 ++++++++-------
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/Documentation/arch/x86/amd-debugging.rst b/Documentation/arch/x86/amd-debugging.rst
index dea8a918c71b..d92bf59d62c7 100644
--- a/Documentation/arch/x86/amd-debugging.rst
+++ b/Documentation/arch/x86/amd-debugging.rst
@@ -52,6 +52,7 @@ report generated from this script to
Spurious s2idle wakeups from an IRQ
===================================
+
Spurious wakeups will generally have an IRQ set to ``/sys/power/pm_wakeup_irq``.
This can be matched to ``/proc/interrupts`` to determine what device woke the system.
@@ -134,6 +135,7 @@ The ``amd_s2idle.py`` script will capture most of these artifacts for you.
s2idle PM debug messages
========================
+
During the s2idle flow on AMD systems, the ACPI LPS0 driver is responsible
to check all uPEP constraints. Failing uPEP constraints does not prevent
s0i3 entry. This means that if some constraints are not met, it is possible
@@ -160,6 +162,7 @@ After doing this, run the suspend cycle and look specifically for errors around:
Historical examples of s2idle issues
====================================
+
To help understand the types of issues that can occur and how to debug them,
here are some historical examples of s2idle issues that have been resolved.
@@ -248,6 +251,7 @@ state entry.
Runtime power consumption issues
================================
+
Runtime power consumption is influenced by many factors, including but not
limited to the configuration of the PCIe Active State Power Management (ASPM),
the display brightness, the EPP policy of the CPU, and the power management
@@ -272,6 +276,7 @@ the battery life when more heavily biased towards performance.
BIOS debug messages
===================
+
Most OEM machines don't have a serial UART for outputting kernel or BIOS
debug messages. However BIOS debug messages are useful for understanding
both BIOS bugs and bugs with the Linux kernel drivers that call BIOS AML.
@@ -321,6 +326,7 @@ to help parse the messages.
Random reboot issues
====================
+
When a random reboot occurs, the high-level reason for the reboot is stored
in a register that will persist onto the next boot.
@@ -338,7 +344,7 @@ There are 6 classes of reasons for the reboot:
"0", "Pin", "thermal pin BP_THERMTRIP_L was tripped"
"1", "Pin", "power button was pressed for 4 seconds"
- "2", "Pin", "shutdown pin was shorted"
+ "2", "Pin", "shutdown pin was tripped"
"4", "Remote", "remote ASF power off command was received"
"9", "Internal", "internal CPU thermal limit was tripped"
"16", "Pin", "system reset pin BP_SYS_RST_L was tripped"
@@ -346,8 +352,8 @@ There are 6 classes of reasons for the reboot:
"18", "Software", "software wrote 0x4 to reset control register 0xCF9"
"19", "Software", "software wrote 0x6 to reset control register 0xCF9"
"20", "Software", "software wrote 0xE to reset control register 0xCF9"
- "21", "Sleep", "ACPI power state transition occurred"
- "22", "Pin", "keyboard reset pin KB_RST_L was asserted"
+ "21", "ACPI-state", "ACPI power state transition occurred"
+ "22", "Pin", "keyboard reset pin KB_RST_L was tripped"
"23", "Internal", "internal CPU shutdown event occurred"
"24", "Hardware", "system failed to boot before failed boot timer expired"
"25", "Hardware", "hardware watchdog timer expired"
@@ -357,6 +363,6 @@ There are 6 classes of reasons for the reboot:
"30", "Internal", "a parity error occurred"
"31", "Internal", "a software sync flood event occurred"
-This information is read by the kernel at bootup and is saved into the
-kernel ring buffer. When a random reboot occurs this message can be helpful
-to determine the next component to debug such an issue.
+This information is read by the kernel at bootup and printed into
+the syslog. When a random reboot occurs this message can be helpful
+to determine the next component to debug.
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 04b11e7c1bf5..56c281f086f1 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1241,18 +1241,18 @@ void amd_check_microcode(void)
}
static const char * const s5_reset_reason_txt[] = {
- [0] = "thermal pin BP_THERMTRIP_L was tripped",
- [1] = "power button was pressed for 4 seconds",
- [2] = "shutdown pin was shorted",
- [4] = "remote ASF power off command was received",
- [9] = "internal CPU thermal limit was tripped",
+ [0] = "thermal pin BP_THERMTRIP_L was tripped",
+ [1] = "power button was pressed for 4 seconds",
+ [2] = "shutdown pin was tripped",
+ [4] = "remote ASF power off command was received",
+ [9] = "internal CPU thermal limit was tripped",
[16] = "system reset pin BP_SYS_RST_L was tripped",
[17] = "software issued PCI reset",
[18] = "software wrote 0x4 to reset control register 0xCF9",
[19] = "software wrote 0x6 to reset control register 0xCF9",
[20] = "software wrote 0xE to reset control register 0xCF9",
[21] = "ACPI power state transition occurred",
- [22] = "keyboard reset pin KB_RST_L was asserted",
+ [22] = "keyboard reset pin KB_RST_L was tripped",
[23] = "internal CPU shutdown event occurred",
[24] = "system failed to boot before failed boot timer expired",
[25] = "hardware watchdog timer expired",
@@ -1283,9 +1283,10 @@ static __init int print_s5_reset_status_mmio(void)
if (!(value & BIT(i)))
continue;
- if (s5_reset_reason_txt[i])
+ if (s5_reset_reason_txt[i]) {
pr_info("x86/amd: Previous system reset reason [0x%08lx]: %s\n",
value, s5_reset_reason_txt[i]);
+ }
}
return 0;On Sun, May 04, 2025 at 09:03:57AM +0200, Ingo Molnar wrote:
> Patch attached to clean this all up.
Ack, just merge it into Mario's original patch.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 5/4/2025 4:52 AM, Borislav Petkov wrote: > On Sun, May 04, 2025 at 09:03:57AM +0200, Ingo Molnar wrote: >> Patch attached to clean this all up. > > Ack, just merge it into Mario's original patch. > > Thx. > Yeah no concerns on my side to just squash it in. If you keep it separate though here's a tag: Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 5b91231c3afd2d75b4efbd40854655ae3b8664a5
Gitweb: https://git.kernel.org/tip/5b91231c3afd2d75b4efbd40854655ae3b8664a5
Author: Ingo Molnar <mingo@kernel.org>
AuthorDate: Sun, 04 May 2025 09:04:01 +02:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Mon, 05 May 2025 07:17:03 +02:00
x86/CPU/AMD: Clean up the last-reset printing code a bit
- Use consistent .rst formatting
- Fix 'Sleep' class field to 'ACPI-State'
- Standardize pin messages around the 'tripped' verbiage
- Remove reference to ring-buffer printing & simplify
the wording
- Use curly braces for multi-line conditional statements
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Borislav Petkov <bp@alien8.de>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Yazen Ghannam <yazen.ghannam@amd.com>
Cc: linux-tip-commits@vger.kernel.org
Link: https://lore.kernel.org/r/aBcRXYkJlfySzBEx@gmail.com
---
Documentation/arch/x86/amd-debugging.rst | 18 ++++++++++++------
arch/x86/kernel/cpu/amd.c | 15 ++++++++-------
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/Documentation/arch/x86/amd-debugging.rst b/Documentation/arch/x86/amd-debugging.rst
index dea8a91..d92bf59 100644
--- a/Documentation/arch/x86/amd-debugging.rst
+++ b/Documentation/arch/x86/amd-debugging.rst
@@ -52,6 +52,7 @@ report generated from this script to
Spurious s2idle wakeups from an IRQ
===================================
+
Spurious wakeups will generally have an IRQ set to ``/sys/power/pm_wakeup_irq``.
This can be matched to ``/proc/interrupts`` to determine what device woke the system.
@@ -134,6 +135,7 @@ The ``amd_s2idle.py`` script will capture most of these artifacts for you.
s2idle PM debug messages
========================
+
During the s2idle flow on AMD systems, the ACPI LPS0 driver is responsible
to check all uPEP constraints. Failing uPEP constraints does not prevent
s0i3 entry. This means that if some constraints are not met, it is possible
@@ -160,6 +162,7 @@ After doing this, run the suspend cycle and look specifically for errors around:
Historical examples of s2idle issues
====================================
+
To help understand the types of issues that can occur and how to debug them,
here are some historical examples of s2idle issues that have been resolved.
@@ -248,6 +251,7 @@ state entry.
Runtime power consumption issues
================================
+
Runtime power consumption is influenced by many factors, including but not
limited to the configuration of the PCIe Active State Power Management (ASPM),
the display brightness, the EPP policy of the CPU, and the power management
@@ -272,6 +276,7 @@ the battery life when more heavily biased towards performance.
BIOS debug messages
===================
+
Most OEM machines don't have a serial UART for outputting kernel or BIOS
debug messages. However BIOS debug messages are useful for understanding
both BIOS bugs and bugs with the Linux kernel drivers that call BIOS AML.
@@ -321,6 +326,7 @@ to help parse the messages.
Random reboot issues
====================
+
When a random reboot occurs, the high-level reason for the reboot is stored
in a register that will persist onto the next boot.
@@ -338,7 +344,7 @@ There are 6 classes of reasons for the reboot:
"0", "Pin", "thermal pin BP_THERMTRIP_L was tripped"
"1", "Pin", "power button was pressed for 4 seconds"
- "2", "Pin", "shutdown pin was shorted"
+ "2", "Pin", "shutdown pin was tripped"
"4", "Remote", "remote ASF power off command was received"
"9", "Internal", "internal CPU thermal limit was tripped"
"16", "Pin", "system reset pin BP_SYS_RST_L was tripped"
@@ -346,8 +352,8 @@ There are 6 classes of reasons for the reboot:
"18", "Software", "software wrote 0x4 to reset control register 0xCF9"
"19", "Software", "software wrote 0x6 to reset control register 0xCF9"
"20", "Software", "software wrote 0xE to reset control register 0xCF9"
- "21", "Sleep", "ACPI power state transition occurred"
- "22", "Pin", "keyboard reset pin KB_RST_L was asserted"
+ "21", "ACPI-state", "ACPI power state transition occurred"
+ "22", "Pin", "keyboard reset pin KB_RST_L was tripped"
"23", "Internal", "internal CPU shutdown event occurred"
"24", "Hardware", "system failed to boot before failed boot timer expired"
"25", "Hardware", "hardware watchdog timer expired"
@@ -357,6 +363,6 @@ There are 6 classes of reasons for the reboot:
"30", "Internal", "a parity error occurred"
"31", "Internal", "a software sync flood event occurred"
-This information is read by the kernel at bootup and is saved into the
-kernel ring buffer. When a random reboot occurs this message can be helpful
-to determine the next component to debug such an issue.
+This information is read by the kernel at bootup and printed into
+the syslog. When a random reboot occurs this message can be helpful
+to determine the next component to debug.
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 9a8c590..469afcd 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1240,18 +1240,18 @@ void amd_check_microcode(void)
}
static const char * const s5_reset_reason_txt[] = {
- [0] = "thermal pin BP_THERMTRIP_L was tripped",
- [1] = "power button was pressed for 4 seconds",
- [2] = "shutdown pin was shorted",
- [4] = "remote ASF power off command was received",
- [9] = "internal CPU thermal limit was tripped",
+ [0] = "thermal pin BP_THERMTRIP_L was tripped",
+ [1] = "power button was pressed for 4 seconds",
+ [2] = "shutdown pin was tripped",
+ [4] = "remote ASF power off command was received",
+ [9] = "internal CPU thermal limit was tripped",
[16] = "system reset pin BP_SYS_RST_L was tripped",
[17] = "software issued PCI reset",
[18] = "software wrote 0x4 to reset control register 0xCF9",
[19] = "software wrote 0x6 to reset control register 0xCF9",
[20] = "software wrote 0xE to reset control register 0xCF9",
[21] = "ACPI power state transition occurred",
- [22] = "keyboard reset pin KB_RST_L was asserted",
+ [22] = "keyboard reset pin KB_RST_L was tripped",
[23] = "internal CPU shutdown event occurred",
[24] = "system failed to boot before failed boot timer expired",
[25] = "hardware watchdog timer expired",
@@ -1282,9 +1282,10 @@ static __init int print_s5_reset_status_mmio(void)
if (!(value & BIT(i)))
continue;
- if (s5_reset_reason_txt[i])
+ if (s5_reset_reason_txt[i]) {
pr_info("x86/amd: Previous system reset reason [0x%08lx]: %s\n",
value, s5_reset_reason_txt[i]);
+ }
}
return 0;© 2016 - 2026 Red Hat, Inc.