Public bug reported:
Description
This system consistently enters suspend successfully but fails to resume
when using ACPI S3 ("deep"). The failure occurs very early during resume
and leaves the system completely unresponsive, requiring a hard
power‑cycle.
The hardware is a Wo‑We R5 mini PC with an AMD Ryzen 5 3550H (Picasso /
Raven2) CPU and AMI UEFI firmware (ADB20D 1.04, dated 2025‑04‑28).
The issue is reproducible with the Ubuntu 25.10 kernel
(`6.17.0-8-generic`).
## Reproduction (S3 / deep)
1. Boot the system normally.
2. Trigger suspend using:
sudo systemctl suspend
3. Allow the system to enter suspend.
4. Attempt to wake using keyboard, mouse, or power button.
## Observed result
* System appears to exit suspend partially:
* fans spin up
* power LED becomes steady
* No HDMI output (monitor reports no signal)
* Keyboard and mouse do not respond
* SSH is unreachable
* Magic SysRq does not produce any response
* System remains in this state indefinitely until powered off
After reboot, logs from the previous boot show:
PM: suspend entry (deep)
There are **no resume‑related log entries** (e.g. "PM: resume from
suspend", "ACPI: Waking up from system sleep state S3", etc.).
I assume the resume failure occurs **before kernel logging and
interrupts are restored**.
## Expected result
The system should resume to a working state with display, input, and
networking restored.
## Additional diagnostics
Magic SysRq commands were tested during the hang (r/e/i/s/u) and
produced no observable effect, indicating the kernel is no longer
executing normally after the wake attempt.
The failure is therefore not limited to graphics or userspace and
appears to be a hard early‑resume hang.
## s2idle behaviour
When forcing suspend‑to‑idle (S0 idle) instead of S3:
mem_sleep_default=s2idle
the system **does resume successfully**, but only if the following
kernel parameter is also present:
no_console_suspend
If `no_console_suspend` is removed, suspend‑to‑idle resumes also begin
to hang again in a similar way.
This suggests the resume path is **timing‑sensitive**, and that keeping
the console active during suspend/resume alters execution timing in a
way that avoids the failure.
## Notes
* The system firmware appears to support S3 (`/sys/power/mem_sleep` advertises `deep`), but resume is consistently broken.
* This does not appear to be a GNOME or userspace issue; failures occur with manual suspend and before userspace regains control.
* Kernel log‑level suppression (`loglevel=3`) does not reliably affect the behaviour.
* A userspace workaround was required to handle cosmetic early DRM messages, but this does not influence the underlying resume reliability.
## Current workaround (for operability)
The system is currently operated with:
mem_sleep_default=s2idle no_console_suspend
This configuration restores reliable suspend/resume behaviour, but S3
("deep") cannot be used.
## Conclusion
Suspend‑to‑RAM (S3) resume appears to be fundamentally broken on this
AMD Picasso (Raven2) platform with the current firmware, failing
extremely early during resume. Suspend‑to‑idle works but is sensitive to
timing and requires `no_console_suspend` to avoid hangs.
This may be a candidate for documentation as unsupported S3 on this
platform, or for a platform/DMI‑based quirk to avoid the broken resume
path.
## personal note
I can provide further details if needed.
This was worked out by me using AI help but I have read every word of this summary and tested all the steps.
My system now works with this work-around and I submit this bug report in good faith to hopefully help others.
ProblemType: Bug
DistroRelease: Ubuntu 25.10
Package: linux-image-6.17.0-8-generic 6.17.0-8.8
ProcVersionSignature: Ubuntu 6.17.0-8.8-generic 6.17.2
Uname: Linux 6.17.0-8-generic x86_64
ApportVersion: 2.33.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: sebastian 3488 F.... wireplumber
/dev/snd/controlC0: sebastian 3488 F.... wireplumber
/dev/snd/seq: sebastian 3472 F.... pipewire
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Sun Jan 25 13:31:02 2026
InstallationDate: Installed on 2025-11-28 (58 days ago)
InstallationMedia: Ubuntu 25.10 "Questing Quokka" - Release amd64 (20251007)
MachineType: wo-we P6
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-8-generic root=UUID=266e1a2f-f26a-44e5-b87f-d980fa5c3454 ro quiet splash no_console_suspend mem_sleep_default=s2idle crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
RelatedPackageVersions:
firmware-sof N/A
linux-firmware 20250901.git993ff19b-0ubuntu1.5
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/28/2025
dmi.bios.release: 1.4
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: ADB20D 1.04
dmi.board.asset.tag: Default string
dmi.board.name: ADB20
dmi.board.vendor: Shanghai Hub Union Industural Co.,Ltd
dmi.board.version: Default string
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 35
dmi.chassis.version: V1.0
dmi.ec.firmware.release: 3.14
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrADB20D1.04:bd04/28/2025:br1.4:efr3.14:svnwo-we:pnP6:pvrDefaultstring:rvnShanghaiHubUnionIndusturalCo.,Ltd:rnADB20:rvrDefaultstring:cvn:ct35:cvrV1.0:sku2502:
dmi.product.family: ADB20
dmi.product.name: P6
dmi.product.sku: 2502
dmi.product.version: Default string
dmi.sys.vendor: wo-we
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug questing wayland-session
** Description changed:
Description
This system consistently enters suspend successfully but fails to resume
when using ACPI S3 ("deep"). The failure occurs very early during resume
and leaves the system completely unresponsive, requiring a hard
power‑cycle.
The hardware is a Wo‑We R5 mini PC with an AMD Ryzen 5 3550H (Picasso /
Raven2) CPU and AMI UEFI firmware (ADB20D 1.04, dated 2025‑04‑28).
The issue is reproducible with the Ubuntu 25.10 kernel
(`6.17.0-8-generic`).
## Reproduction (S3 / deep)
1. Boot the system normally.
2. Trigger suspend using:
- sudo systemctl suspend
+ sudo systemctl suspend
3. Allow the system to enter suspend.
4. Attempt to wake using keyboard, mouse, or power button.
## Observed result
* System appears to exit suspend partially:
- * fans spin up
- * power LED becomes steady
+ * fans spin up
+ * power LED becomes steady
* No HDMI output (monitor reports no signal)
* Keyboard and mouse do not respond
* SSH is unreachable
* Magic SysRq does not produce any response
* System remains in this state indefinitely until powered off
After reboot, logs from the previous boot show:
- PM: suspend entry (deep)
+ PM: suspend entry (deep)
There are **no resume‑related log entries** (e.g. "PM: resume from
suspend", "ACPI: Waking up from system sleep state S3", etc.).
I assume the resume failure occurs **before kernel logging and
interrupts are restored**.
## Expected result
The system should resume to a working state with display, input, and
networking restored.
-
## Additional diagnostics
Magic SysRq commands were tested during the hang (r/e/i/s/u) and
produced no observable effect, indicating the kernel is no longer
executing normally after the wake attempt.
The failure is therefore not limited to graphics or userspace and
appears to be a hard early‑resume hang.
## s2idle behaviour
When forcing suspend‑to‑idle (S0 idle) instead of S3:
- mem_sleep_default=s2idle
+ mem_sleep_default=s2idle
the system **does resume successfully**, but only if the following
kernel parameter is also present:
- no_console_suspend
+ no_console_suspend
If `no_console_suspend` is removed, suspend‑to‑idle resumes also begin
to hang again in a similar way.
This suggests the resume path is **timing‑sensitive**, and that keeping
the console active during suspend/resume alters execution timing in a
way that avoids the failure.
## Notes
* The system firmware appears to support S3 (`/sys/power/mem_sleep` advertises `deep`), but resume is consistently broken.
* This does not appear to be a GNOME or userspace issue; failures occur with manual suspend and before userspace regains control.
* Kernel log‑level suppression (`loglevel=3`) does not reliably affect the behaviour.
* A userspace workaround was required to handle cosmetic early DRM messages, but this does not influence the underlying resume reliability.
## Current workaround (for operability)
The system is currently operated with:
- mem_sleep_default=s2idle no_console_suspend
+ mem_sleep_default=s2idle no_console_suspend
This configuration restores reliable suspend/resume behaviour, but S3
("deep") cannot be used.
## Conclusion
Suspend‑to‑RAM (S3) resume appears to be fundamentally broken on this
AMD Picasso (Raven2) platform with the current firmware, failing
extremely early during resume. Suspend‑to‑idle works but is sensitive to
timing and requires `no_console_suspend` to avoid hangs.
This may be a candidate for documentation as unsupported S3 on this
platform, or for a platform/DMI‑based quirk to avoid the broken resume
path.
-
## personal note
I can provide further details if needed.
- This was worked out by me using AI help but I have ready every word of this summary and tested many things.
+ This was worked out by me using AI help but I have read every word of this summary and tested all the steps.
My system now works with this work-around and I submit this bug report in good faith to hopefully help others.
ProblemType: Bug
DistroRelease: Ubuntu 25.10
Package: linux-image-6.17.0-8-generic 6.17.0-8.8
ProcVersionSignature: Ubuntu 6.17.0-8.8-generic 6.17.2
Uname: Linux 6.17.0-8-generic x86_64
ApportVersion: 2.33.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
- USER PID ACCESS COMMAND
- /dev/snd/controlC1: sebastian 3488 F.... wireplumber
- /dev/snd/controlC0: sebastian 3488 F.... wireplumber
- /dev/snd/seq: sebastian 3472 F.... pipewire
+ USER PID ACCESS COMMAND
+ /dev/snd/controlC1: sebastian 3488 F.... wireplumber
+ /dev/snd/controlC0: sebastian 3488 F.... wireplumber
+ /dev/snd/seq: sebastian 3472 F.... pipewire
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Sun Jan 25 13:31:02 2026
InstallationDate: Installed on 2025-11-28 (58 days ago)
InstallationMedia: Ubuntu 25.10 "Questing Quokka" - Release amd64 (20251007)
MachineType: wo-we P6
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-8-generic root=UUID=266e1a2f-f26a-44e5-b87f-d980fa5c3454 ro quiet splash no_console_suspend mem_sleep_default=s2idle crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
RelatedPackageVersions:
- firmware-sof N/A
- linux-firmware 20250901.git993ff19b-0ubuntu1.5
+ firmware-sof N/A
+ linux-firmware 20250901.git993ff19b-0ubuntu1.5
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/28/2025
dmi.bios.release: 1.4
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: ADB20D 1.04
dmi.board.asset.tag: Default string
dmi.board.name: ADB20
dmi.board.vendor: Shanghai Hub Union Industural Co.,Ltd
dmi.board.version: Default string
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 35
dmi.chassis.version: V1.0
dmi.ec.firmware.release: 3.14
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrADB20D1.04:bd04/28/2025:br1.4:efr3.14:svnwo-we:pnP6:pvrDefaultstring:rvnShanghaiHubUnionIndusturalCo.,Ltd:rnADB20:rvrDefaultstring:cvn:ct35:cvrV1.0:sku2502:
dmi.product.family: ADB20
dmi.product.name: P6
dmi.product.sku: 2502
dmi.product.version: Default string
dmi.sys.vendor: wo-we
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2139016
Title:
S3 (deep) resume hard hang on AMD Ryzen 5 3550H (Picasso); s2idle only
works with no_console_suspend
Status in linux package in Ubuntu:
New
Bug description:
Description
This system consistently enters suspend successfully but fails to
resume when using ACPI S3 ("deep"). The failure occurs very early
during resume and leaves the system completely unresponsive, requiring
a hard power‑cycle.
The hardware is a Wo‑We R5 mini PC with an AMD Ryzen 5 3550H (Picasso
/ Raven2) CPU and AMI UEFI firmware (ADB20D 1.04, dated 2025‑04‑28).
The issue is reproducible with the Ubuntu 25.10 kernel
(`6.17.0-8-generic`).
## Reproduction (S3 / deep)
1. Boot the system normally.
2. Trigger suspend using:
sudo systemctl suspend
3. Allow the system to enter suspend.
4. Attempt to wake using keyboard, mouse, or power button.
## Observed result
* System appears to exit suspend partially:
* fans spin up
* power LED becomes steady
* No HDMI output (monitor reports no signal)
* Keyboard and mouse do not respond
* SSH is unreachable
* Magic SysRq does not produce any response
* System remains in this state indefinitely until powered off
After reboot, logs from the previous boot show:
PM: suspend entry (deep)
There are **no resume‑related log entries** (e.g. "PM: resume from
suspend", "ACPI: Waking up from system sleep state S3", etc.).
I assume the resume failure occurs **before kernel logging and
interrupts are restored**.
## Expected result
The system should resume to a working state with display, input, and
networking restored.
## Additional diagnostics
Magic SysRq commands were tested during the hang (r/e/i/s/u) and
produced no observable effect, indicating the kernel is no longer
executing normally after the wake attempt.
The failure is therefore not limited to graphics or userspace and
appears to be a hard early‑resume hang.
## s2idle behaviour
When forcing suspend‑to‑idle (S0 idle) instead of S3:
mem_sleep_default=s2idle
the system **does resume successfully**, but only if the following
kernel parameter is also present:
no_console_suspend
If `no_console_suspend` is removed, suspend‑to‑idle resumes also begin
to hang again in a similar way.
This suggests the resume path is **timing‑sensitive**, and that
keeping the console active during suspend/resume alters execution
timing in a way that avoids the failure.
## Notes
* The system firmware appears to support S3 (`/sys/power/mem_sleep` advertises `deep`), but resume is consistently broken.
* This does not appear to be a GNOME or userspace issue; failures occur with manual suspend and before userspace regains control.
* Kernel log‑level suppression (`loglevel=3`) does not reliably affect the behaviour.
* A userspace workaround was required to handle cosmetic early DRM messages, but this does not influence the underlying resume reliability.
## Current workaround (for operability)
The system is currently operated with:
mem_sleep_default=s2idle no_console_suspend
This configuration restores reliable suspend/resume behaviour, but S3
("deep") cannot be used.
## Conclusion
Suspend‑to‑RAM (S3) resume appears to be fundamentally broken on this
AMD Picasso (Raven2) platform with the current firmware, failing
extremely early during resume. Suspend‑to‑idle works but is sensitive
to timing and requires `no_console_suspend` to avoid hangs.
This may be a candidate for documentation as unsupported S3 on this
platform, or for a platform/DMI‑based quirk to avoid the broken resume
path.
## personal note
I can provide further details if needed.
This was worked out by me using AI help but I have read every word of this summary and tested all the steps.
My system now works with this work-around and I submit this bug report in good faith to hopefully help others.
ProblemType: Bug
DistroRelease: Ubuntu 25.10
Package: linux-image-6.17.0-8-generic 6.17.0-8.8
ProcVersionSignature: Ubuntu 6.17.0-8.8-generic 6.17.2
Uname: Linux 6.17.0-8-generic x86_64
ApportVersion: 2.33.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: sebastian 3488 F.... wireplumber
/dev/snd/controlC0: sebastian 3488 F.... wireplumber
/dev/snd/seq: sebastian 3472 F.... pipewire
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Sun Jan 25 13:31:02 2026
InstallationDate: Installed on 2025-11-28 (58 days ago)
InstallationMedia: Ubuntu 25.10 "Questing Quokka" - Release amd64 (20251007)
MachineType: wo-we P6
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.17.0-8-generic root=UUID=266e1a2f-f26a-44e5-b87f-d980fa5c3454 ro quiet splash no_console_suspend mem_sleep_default=s2idle crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
RelatedPackageVersions:
firmware-sof N/A
linux-firmware 20250901.git993ff19b-0ubuntu1.5
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/28/2025
dmi.bios.release: 1.4
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: ADB20D 1.04
dmi.board.asset.tag: Default string
dmi.board.name: ADB20
dmi.board.vendor: Shanghai Hub Union Industural Co.,Ltd
dmi.board.version: Default string
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 35
dmi.chassis.version: V1.0
dmi.ec.firmware.release: 3.14
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrADB20D1.04:bd04/28/2025:br1.4:efr3.14:svnwo-we:pnP6:pvrDefaultstring:rvnShanghaiHubUnionIndusturalCo.,Ltd:rnADB20:rvrDefaultstring:cvn:ct35:cvrV1.0:sku2502:
dmi.product.family: ADB20
dmi.product.name: P6
dmi.product.sku: 2502
dmi.product.version: Default string
dmi.sys.vendor: wo-we
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2139016/+subscriptions
Комментариев нет:
Отправить комментарий