Which Linux distro are you using?
Ubuntu 26.04
Which release version?
(if rolling release without a release version, skip this question)
(If rolling release, last date updated?)
Which kernel are you using?
7.0.0
Which BIOS version are you using?
4.02
Which Framework Laptop 13 model are you using?
AMD Ryzen™ AI 300 Series
Hi everyone,
I’m trying to diagnose an intermittent shutdown / power-state issue on my Framework Laptop 13 with Ryzen AI 9 HX 370.
System details:
Framework Laptop 13
AMD Ryzen AI 9 HX 370
Ubuntu 26.04
Kernel: 7.0.0-29-generic
BIOS: 04.02
The main symptom is that shutdown sometimes appears to complete from Linux’s point of view, but the laptop does not physically power off.
Typical behavior:
- Ubuntu begins shutdown normally
- Screen goes black
- Power-button LED remains illuminated
- Laptop can stay like this indefinitely
- In one occurrence I left it for approximately 1 hour
- I eventually had to hold the power button to force it off
Sometimes the shutdown instead spends a long time at the Framework/Ubuntu splash before reaching the black-screen state.
This is particularly concerning because I had a previous Framework mainboard that developed similar behavior and eventually stopped booting.
Most important log finding
On a failed/abnormal shutdown after approximately 11.5 hours of uptime, systemd appears to complete shutdown normally:
[41501.877016] systemd[1]: Reached target shutdown.target - System Shutdown.
[41501.877042] systemd[1]: Reached target final.target - Late Shutdown Services.
[41501.877074] systemd[1]: systemd-poweroff.service: Deactivated successfully.
[41501.877084] systemd[1]: Finished systemd-poweroff.service - System Power Off.
[41501.877116] systemd[1]: Reached target poweroff.target - System Power Off.
[41501.877137] systemd[1]: Shutting down.
[41501.931062] systemd-shutdown[1]: Syncing filesystems and block devices.
[41501.946798] systemd-shutdown[1]: Sending SIGTERM to remaining processes…
[41501.947559] systemd-journald[465]: Received SIGTERM from PID 1
So Linux is apparently reaching poweroff.target, but the hardware occasionally remains powered afterward.
Battery-only comparison
I also tested shutdown while completely disconnected from AC power.
The kernel confirms:
ACPI: AC: AC Adapter [ACAD] (off-line)
That battery-only session also reached the normal final shutdown sequence:
[ 249.519439] systemd[1]: Reached target shutdown.target - System Shutdown.
[ 249.519464] systemd[1]: Reached target final.target - Late Shutdown Services.
[ 249.519497] systemd[1]: systemd-poweroff.service: Deactivated successfully.
[ 249.519505] systemd[1]: Finished systemd-poweroff.service - System Power Off.
[ 249.519536] systemd[1]: Reached target poweroff.target - System Power Off.
[ 249.519555] systemd[1]: Shutting down.
[ 249.571051] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 249.580026] systemd-shutdown[1]: Sending SIGTERM to remaining processes…
[ 249.586187] systemd-journald[464]: Journal stopped
Battery-only shutdowns seem to be more reliable so far, although the problem is intermittent.
UCSI / USB-C errors
The system repeatedly produces:
ucsi_acpi USBC000:00: unknown error 256
For example:
Aug 18 21:23:13 kernel: ucsi_acpi USBC000:00: unknown error 256
Aug 18 21:23:13 kernel: ucsi_acpi USBC000:00: unknown error 256
On another boot I saw four of these within about one second:
Aug 18 09:25:09 kernel: ucsi_acpi USBC000:00: unknown error 256
Aug 18 09:25:09 kernel: ucsi_acpi USBC000:00: unknown error 256
Aug 18 09:25:10 kernel: ucsi_acpi USBC000:00: unknown error 256
Aug 18 09:25:10 kernel: ucsi_acpi USBC000:00: unknown error 256
However, these errors also happen when the system is booted on battery with AC explicitly reported as offline, so I don’t think unknown error 256 by itself proves a charger fault.
USB-C / charger behavior
I was originally using an Anker Prime 100W GaN USB-PD charger.
While plugged in, I have occasionally heard what sounds like a charger disconnect/reconnect notification even though I did not touch the cable.
When I manually unplugged and replugged the charger while monitoring:
sudo journalctl -kf | grep -Ei 'ucsi|typec|usb|acpi|power|charger'
I immediately got another:
ucsi_acpi USBC000:00: unknown error 256
Nothing else was plugged into the charger.
I am now also testing a separate single-port Anker Nano 100W charger with a new USB-C cable to eliminate the original charger/cable combination as a variable.
ACPI power-state support
The kernel reports:
ACPI: PM: (supports S0 S4 S5)
so the firmware does advertise S5 soft-off support.
Kernel parameters already removed
Earlier during troubleshooting I had:
ucsi_acpi.force=1
pcie_aspm=off
amdgpu.aspm=0
These have now all been removed.
ucsi_acpi.force=1 was also explicitly reported by this kernel as an unsupported/unknown parameter.
The active kernel command line no longer contains any of those three options.
The shutdown problem has reproduced after removing them, so they do not seem to explain the failure.
AMDGPU
AMDGPU initializes successfully.
One recurring line is:
amdgpu 0000:c1:00.0: Runtime PM not available
but I have not found any obvious GPU timeout, GPU reset, MES timeout, or fatal AMDGPU error associated with the shutdown event itself.
Other potentially relevant hardware
I have a Framework HDMI Expansion Card installed.
It enumerates normally:
Product: HDMI Expansion Card
Manufacturer: Framework
SerialNumber: 11AD1D00EEC0401724320B00
I have not yet established whether the HDMI Expansion Card has anything to do with the issue.
Current hypothesis
At this point it looks like Linux userspace is successfully finishing shutdown, and the failure is happening during the final transition from the kernel/firmware/platform to physical S5 power-off.
Things I’m wondering about:
- EC state / EC firmware
- BIOS / ACPI S5 transition
- USB-C PD controller state
- UCSI / Type-C firmware interaction
- Linux 7.0 kernel regression
- something that accumulates after long uptime
- charger / cable / USB-C bay interaction
- mainboard hardware issue
The long-uptime aspect may be relevant: short battery-only sessions have generally shut down normally, whereas one of the strongest reproductions happened after about 11.5 hours of use.
Questions
Has anyone with the Ryzen AI 300 Framework 13 seen anything similar where:
systemd reaches poweroff.target
display turns off
but the power-button LED remains illuminated indefinitely?
Has anyone found this to be related to:
- BIOS 04.02
- EC firmware
- USB-C PD/UCSI
- kernel 7.0
- HDMI Expansion Card
- long uptime
Also, if anyone knows of an official EC reset / mainboard-state reset procedure for the Ryzen AI 300 model that does not require opening the laptop, I’d be interested.
I have already opened a Framework Support case, but I’m hoping to determine whether this is a known Linux/firmware issue or whether others have seen the same behavior before a hardware failure.
Thanks.