Fedora 39 don't shutdown proprely after resume from sleep

Hi all
I have just installed F39 on my new laptop a Lenovo T14s Gen4 AMD.
For now almost everything seems fine except for a single issue.

If I put my laptop to sleep even once then i wont poweroff completely (nor reboot) , after a brief logo the screen become black and the latoptop stays on and I have to force it to poweroff (long pressing the power button).
Kernel 6.8.7-200

It does shutdown and reboot if I never make it sleep.

Do you have any suggestion?
Thank You

Have you tried updating your machine recently? I know kernel 6.8.7 is fairly new, but these things happen and get patched.

Updated (dnf upgrade --refresh -y)
kernel 6.8.8-200
Saddly still has the same problem.

New hardware often has issues with linux. Unless the vendor has made an effort to support linux, it takes time to reverse engineer, test, and propagate fixes. Sometimes there are workarounds involving different sleep modes. Fix may appear with kernel updates or vendor firmware updates. Lenovo models that are supported on linux can get firmware updates using fwupdtool. Check for available updates with sudo fwupdtool get-updates.

No updates (for now)
I’m aware of that I’m a long time linux user :wink:
I usually don’t buy too current hardware but i read that this laptop worked well on fedora so I took the risk.

So i’ll wait, it’s not a serious issue.

You may want to collect some details for a bug report to make sure the problem gets some attention. If your model is one of the Ubuntu Certified versions you may be able to find a patch or configuration option that allows Ubuntu to resume from sleep.

It is a certified laptop: Lenovo ThinkPad P14s Gen 4 AMD (AMD Ryzen 7 PRO 7840U, Radeon 780M Graphics) certified on Ubuntu 22.04 LTS

I have explained it in an unclear way.
The laptop resumes well, but if It goes to sleep even once, eventually when i try to shut it down it just hang (like in this post Unable to shut down system after latest kernel update).
If i never put it to sleep the issue doesn’t show.

Are you running any containers or skype at the time of the suspend ?

Is this true if no apps are running, I am having the same problem occasionally and I’m trying to see if its being caused by a particular app.

currently F40 loaded on the machine i’m having issues with.

no, the laptop is still new, but I’m on KDE if it counts.

Have you tried the Logs? See if anything is in there. I mean, all the logs not just the critical ones. The issue could be presented there.

There are many errors but I cannot pinpoint a difference between the good case (when it does work) and bad case (when it hungs)

If i activate the console during shutdown i see the same things (more o less) but when it say that it will poweroff the PC the screen becomes black but the laptop stays on (leds are active).

During your scenarios of not being able to shutdown, have you tried dropping down to a Terminal and seeing if anything new comes up or you can shutdown from there?

In the thread you linked earlier, there are many journalctl commands, did you try any of them? We could use more help than just dictation.

it’s too fast to see if there is something different, I don’t have a way to capture the display output right now

I can share the output of

journalctl -b -1 -r >filename.txt

but it’s too long for here

this is the log of when the computer hang at shutdown

this is the log of when it does shutdown properly

I have the same laptop and have the same issue. Almost certain it’s caused by the following issue Bisected: drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11 cause the issue the laptop doesn't repower after reboot or poweroff completely (#3351) · Issues · drm / amd · GitLab

Fortunately there’s already a fix for it, so just need to wait for it to hit the stable kernel release.


It appears that a fix is on the way.

You should confirm that you have the same issue – look at the associated documentation. There is a test script you can and use to check that your system has the problem, and to check whether new kernels fix it.

As you saw, journalctl captures an enormous amount of detail. When submitting journalctl results you need to filter only the entries relevant to your problem. Use man journalctl to learn about the many options that you can use to filter the output. It is useful to run journalctl -b -p 3 after rebooting for kernel updates to see if there are new priority messages. It also helps to note the time a problem occurs so you can jump to messages around that time.

1 Like

Thank you all.
I was unable to find the test script and I don’t feel “brave” enought to patch and recompile the kernel on my own.
But I have the same computer of one of the posters in that issue filling.
Yeah I should study systemctl more :upside_down_face:
I’ll wait for the new kernel and report if it fix the issue.

It is a bit hidden in the patch:

I tested this on SMU 13.0.4 for ~85 cycles with this script, BIOS and didn’t observe any hangs.

echo test_resume > /sys/power/disk
while [ : ]; do

   echo "Starting cycle $i"
   echo disk > /sys/power/state
   echo "Ending cycle $i"
   sleep 5
1 Like

I even open the patch and didn’t noticed that.
I’l try to test it when I’ll have some time I don’t need the laptop.
Thank you.

Hi all
I just update to kernel 6.8.9-200.fc39.x86_64.
The script doesn’t hung my laptop anymore but the issue of the shutdown is still present.

Luckily I’m not the only one, I’ll wait patiently :wink:

The fix is coming in 6.8.10 kernel once it’s released.


1 Like