Additional data point: same regression on the Ubuntu 24.04 LTS HWE kernel, on a
mobile AMD Phoenix platform with integrated graphics only, no discrete GPU and
no PCIe switch. This may widen the scope beyond the reports so far.

## Hardware

- Lenovo ThinkPad P16s Gen 2 AMD (21K90004CK)
- GPU: AMD Phoenix1 [1002:15bf], integrated, amdgpu. No discrete GPU present.
- BIOS: LENOVO R2FET61W (1.41), 2024-11-15; EC firmware 1.30
  (fwupd/LVFS report both as latest available — no pending updates)
- NVMe: KIOXIA KXG8AZNV2T04; root on LVM + ext4
- Secure Boot disabled

## Software

- Ubuntu 24.04.4 LTS (noble), GNOME
- BROKEN: 7.0.0-28-generic (#28~24.04.1, upstream 7.0.12)
- BROKEN: 7.0.0-29-generic (#29~24.04.2)
- GOOD:   6.17.0-40-generic (#40~24.04.1) — multiple consecutive clean poweroffs
- 7.0.0-27 not tested; not offered in the noble HWE stream, so I cannot confirm
  the -27/-28 boundary reported here.

## Symptoms

- Roughly 2 of 3 poweroff attempts hang.
- Display goes dark; power LED and keyboard backlight stay lit; fan keeps 
running.
- Never completes power-off; requires holding the power button.
- Journal ends at exactly the same point reported in this bug:

      systemd[1]: Reached target poweroff.target - System Power Off.
      systemd[1]: Shutting down.
      systemd-shutdown[1]: Syncing filesystems and block devices.
      systemd-shutdown[1]: Sending SIGTERM to remaining processes...
      systemd-journald[456]: Received SIGTERM from PID 1 (systemd-shutdow).
      systemd-journald[456]: Journal stopped

- Magic SysRq at the hang (Alt+SysRq+o) has no effect.

## Isolation already performed — all negative, problem persists

- Reproduces from a bare TTY with no desktop session running.
- Reproduces with rabbitmq-server, mssql-server and apache2 stopped.
- Reproduces with every ACPI wake source disarmed (all entries in
  /proc/acpi/wakeup set to *disabled, plus mhi0 power/wakeup disabled).
- Reproduces with no Thunderbolt dock and no external devices attached.
- Reproduces after unloading VirtualBox out-of-tree modules
  (vboxdrv, vboxnetflt, vboxnetadp) and disabling vboxdrv.service.
- Platform power profile (balanced vs power-saver) makes no difference.
- Firmware is current; no BIOS or EC update available via LVFS.

## Reboot vs poweroff

Initially 5/5 clean reboots on 7.0.0-29 while poweroff was failing ~2 in 3.
A reboot hang was observed later, so reboot is affected too, but at a much lower
rate than poweroff on this machine. This is consistent with the report here that
both paths are affected.

## Firmware observation — possibly relevant to why some platforms hang
hard

I decompiled this machine's DSDT. `_PTS(5)` routes several SMM calls through a
helper that polls a handshake flag in ACPI NVS with no timeout and no iteration
bound:

    OperationRegion (SMI0, SystemIO, 0xB0, 0x02)
    Field (SMI0, ByteAcc, NoLock, Preserve) { APMC, 8, APMD, 8 }

    Method (SMI, 5, Serialized)
    {
        Acquire (MSMI, 0xFFFF)
        CMD = Arg0
        ERR = 0x01
        PAR0 = Arg1 ... PAR3 = Arg4
        APMC = 0xF5
        While ((ERR == 0x01))        // unbounded
        {
            Sleep (0x01)
            APMC = 0xF5
        }
        Local0 = PAR0
        Release (MSMI)
        Return (Local0)
    }

`_PTS(5)` reaches this via `SCMS(0x0D)` (SMI 0x02) and `AWON(0x05)` (SMI 0x12).
If the SMM response is delayed or dropped, the ACPI interpreter spins here
indefinitely and the PM1_CNT SLP_TYP/SLP_EN write never happens — which matches
the observed state (fully powered, EC alive, no OS).

For contrast, Lenovo's own `SECM` method in SSDT1 on this same machine uses the
identical polling idiom but bounds it:

    Local0 = 0x64
    While (((\_SB.SCMD != 0x00) && (Local0 != 0x00)))
    {
        Sleep (0x01)
        Local0--
    }

So the unbounded loop looks like an omission rather than intent. This firmware
defect predates the regression — the machine shipped in 2024 and powered off
reliably for two years — but it may explain why affected platforms wedge
completely instead of merely stalling.

## Not yet tested here

- `pcie_aspm=off` (the workaround noted in this bug)
- 7.0.0-27, to confirm the boundary

Happy to test proposed kernels or collect further data on this platform.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2162959

Title:
  System hangs on shutdown/reboot ~50% of the time since kernel 7.0.0-28
  (PCI/ASPM regression)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162959/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to