https://bugzilla.kernel.org/show_bug.cgi?id=222259
Bug ID: 222259
Summary: Acer Nitro AN16S-61 (AMD Strix): NVMe in second M.2
slot (GPP3, 00:02.1) lost on every s2idle resume
Product: ACPI
Version: 2.5
Kernel Version: 7.0.0-43-generic, also failing on 6.18.63
Hardware: AMD
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Power-Sleep-Wake
Assignee: [email protected]
Reporter: [email protected]
Regression: No
Created attachment 311452
--> https://bugzilla.kernel.org/attachment.cgi?id=311452&action=edit
dmesg excerpt: same failure on mainline 6.18.63 LTS
Hardware: Acer Nitro AN16S-61, AMD Strix (Ryzen AI 300), BIOS V1.53 (latest),
two M.2 slots:
- slot A: root port 0000:00:03.2, ACPI \_SB.PCI0.GP10 (SSDT22)
- slot B: root port 0000:00:02.1, ACPI \_SB.PCI0.GPP3 (SSDT21)
Symptom: any NVMe drive in slot B is lost on every s2idle resume that reaches
the deepest state:
nvme 0000:60:00.0: Unable to change power state from D3hot to D0, device
inaccessible
nvme 0000:60:00.0: Unable to change power state from D3cold to D0, device
inaccessible
nvme nvme1: Disabling device after reset failure: -19
The controller stays "dead" until a full power cycle; PCI remove/rescan of the
device and of the
root port does not recover it. If the system disk is in slot B the system
crashes on resume.
Afterwards every further suspend aborts with "nvme_suspend returns -16" (dead
controller), so the
machine can never sleep again until reboot. Light s2idle ("Last suspend didn't
reach deepest
state") does not trigger it.
Isolation (all reproduced):
- 3 drives fail in slot B: Micron 2500, Samsung 980 PRO, Crucial P310. None
fail in slot A.
- 2 independent installs (clean Kubuntu 26.04 and an older install) fail the
same way.
- Kernels 6.18.63 (mainline LTS), 7.0.0-14 and 7.0.0-43 (Ubuntu) all fail.
- nvme.quirks=<id>:^simple_suspend (quirk confirmed cleared): still lost,
plus 60 s resume stall.
- d3cold_allowed=0 on root port 00:02.1: still lost.
- pcie_port_pm=off: drives in BOTH slots are lost on resume.
- Windows suspends/resumes fine with a drive in slot B.
ACPI analysis: SSDT21 (GPP3) and SSDT22 (GP10) are identical except for one
branch in
GPPx.PWEN, which P0NV._ON calls:
If ((PDEV == 0x02) && (PFUN == One)) -> Local1 = EC0.MSP0, power-up via
EC0.ECMD (0x64)
else -> Local1 = EC0.MSP1, power-up via
EC0.ECMD (0x65)
If (((PRST & One) == Zero) && (Local1 == Zero)) { clock gate, ECMD, sleeps,
PRST |= 0xC0,
ALIB (0x13, ...), link poll, ... }
P0NV._OFF only clears D0NV. After a failed resume, EC register 0x6E reads 0x03
(MSP0 = 1, MSP1 = 1)
while the slot B device is inaccessible, so the power-up sequence for slot B is
apparently skipped
because the EC still reports the slot as powered. With pcie_port_pm=off the _ON
path is never
taken and both slots fail, which is consistent with the slots relying on PWEN
after S0i3.
Runtime reproduction (no suspend needed): after the slot B device is removed at
boot, the root
port runtime-suspends to D3cold. Forcing it back to D0 (power/control=on) never
brings the link
up: LnkSta "Train+ DLActive-" with SltSta "PresDet+". At that point slot A and
slot B read the
same: clock-request bits in 0xFED80E00 are 00 for both, both PERST# GPIOs (78
for GPP3, 79 for
GP10) are released, and EC MSP0 = MSP1 = 1.
Running the firmware's own GPP3 power-up by hand does not recover it either:
assert PERST#
(GPIO78), \_SB.PCI0.LPC0.EC0.ECMD(0x64), wait 200 ms, release PERST#,
\_SB.ALIB(0x13, 0x11),
then a PCIe link retrain and rescan. The link still never trains and EC 0x6E
stays 0x03. So once
slot B has been powered down, only a full platform reset restores it. An ACPI
override that
forces the PWEN path therefore cannot fix it. The fault is below the ACPI code,
in the EC or the
platform slot-power control.
Attachments: dmesg excerpts of failing resumes on 7.0.0-43 and 6.18.63, lspci
-vv of both root ports in the failed state, disassembled DSDT, SSDT21 (GPP3)
and SSDT22 (GP10).
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
