Documentation/arch/x86/amd-debugging.rst

Source file repositories/reference/linux-study-clean/Documentation/arch/x86/amd-debugging.rst

File Facts

System
Linux kernel
Corpus path
Documentation/arch/x86/amd-debugging.rst
Extension
.rst
Size
15928 bytes
Lines
369
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

Debugging AMD Zen systems
+++++++++++++++++++++++++

Introduction
============

This document describes techniques that are useful for debugging issues with
AMD Zen systems.  It is intended for use by developers and technical users
to help identify and resolve issues.

S3 vs s2idle
============

On AMD systems, it's not possible to simultaneously support suspend-to-RAM (S3)
and suspend-to-idle (s2idle).  To confirm which mode your system supports you
can look at ``cat /sys/power/mem_sleep``.  If it shows ``s2idle [deep]`` then
*S3* is supported.  If it shows ``[s2idle]`` then *s2idle* is
supported.

On systems that support *S3*, the firmware will be utilized to put all hardware into
the appropriate low power state.

On systems that support *s2idle*, the kernel will be responsible for transitioning devices
into the appropriate low power state. When all devices are in the appropriate low
power state, the hardware will transition into a hardware sleep state.

After a suspend cycle you can tell how much time was spent in a hardware sleep
state by looking at ``cat /sys/power/suspend_stats/last_hw_sleep``.

This flowchart explains how the AMD s2idle suspend flow works.

.. kernel-figure:: suspend.svg

This flowchart explains how the amd s2idle resume flow works.

.. kernel-figure:: resume.svg

s2idle debugging tool
=====================

As there are a lot of places that problems can occur, a debugging tool has been
created at
`amd-debug-tools <https://git.kernel.org/pub/scm/linux/kernel/git/superm1/amd-debug-tools.git/about/>`_
that can help test for common problems and offer suggestions.

If you have an s2idle issue, it's best to start with this and follow instructions
from its findings.  If you continue to have an issue, raise a bug with the
report generated from this script to
`drm/amd gitlab <https://gitlab.freedesktop.org/drm/amd/-/issues/new?issuable_template=s2idle_BUG_TEMPLATE>`_.

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.

If this isn't enough to debug the problem, then the following sysfs files
can be set to add more verbosity to the wakeup process: ::

  # echo 1 | sudo tee /sys/power/pm_debug_messages
  # echo 1 | sudo tee /sys/power/pm_print_times

After making those changes, the kernel will display messages that can
be traced back to kernel s2idle loop code as well as display any active
GPIO sources while waking up.

If the wakeup is caused by the ACPI SCI, additional ACPI debugging may be
needed.  These commands can enable additional trace data: ::

Annotation

Implementation Notes