[RESPONDED] AMD 7040 Linux - Boiling hot, stuck in sleep(?)

Framework Laptop 13 Linux
1

Yesterday, I came back to my laptop absolutely boiling hot, too hot to touch. It was plugged in on a desk, fully charged. When I opened it, the LED blinking indicated sleep mode, but it did not wake on its own. I forcefully powered off by holding the button, then powered back on, and it booted normally with the fan blasting until things came down to temp.

I don’t really have any reproduction steps, but after looking at other forum posts, I suspect I may have plugged it in after putting it to sleep - which is a known issue currently with the 7040 series. It seemed to stay in a half sleep/half running state, such that the fan did not turn on.

I’m more or less just starting to document this in case other people experience it. If it happens again then I might be able to produce more specific reproduction steps. I’m not going to purposefully try to reproduce this (for risk of hardware damage).

Once I got into my OS I saw my SSD reading temperatures > 60°C - I’m sure it was higher before, since that was after the fan was running for at least a minute or so. Didn’t catch CPU temperatures until they got into reasonable ranges (~55-60).

  • Arch Linux, kernel 6.6.1-arch1-1
  • R5 7640U
2

Can almost guarantee this is the issue. I would never run a kernel on my daily before the 5th release. Try the lts or a kernel that is not on the first release revision. The other potential issue is an incorrectly configured sleep. Are you using LUKS encryption and have you made the necessary modification to allow for sleep?

3

I’ve ran Arch linux as my main OS for years - rarely an issue. Especially on 7040 series, Framework themselves are pushing to run the newest kernels we possibly can. (Though that’s on Ubuntu/Fedora).

However, I am running LUKS encryption. I’ll double check and make sure I made that necessary change.

Its worth noting I’ve been using the laptop just fine for ~ 2 weeks now, sleep and all. This is the first time this specific thing has occurred. The more I think about it, the more I think it’s the bug regarding plugging in a charger after already in sleep. I don’t think I’ve done that before last night.

I just want to reiterate I’m not particularly concerned about it right now, I just wanted to document in case other people are looking/searching.

1 Like
4

Sounds like you’re already aware, but you likely hit this:

Currently, if you close the lid (to suspend the system) and plug in AC, the system will re-wake despite the lid still being closed.

Fingers crossed this will be addressed in a firmware update, but in the meantime there’s a workaround (for Linux users):

Remove the first line to preserve wake on open.

1 Like
5

First thing to note for others reading this (not OP, you are aware, this is for other readers):

That said, I’d see about adding this in GRUB:

rtc_cmos.use_acpi_alarm=1

You can run this script to dig into things a bit deeper.

1 Like
6

I’ll try setting that kernel parameter (as well as the second udev rule above) and report back if it happens again.

Thanks for offering some help even for ‘unsupported’ distros. :slight_smile:

1 Like
7

Happy to help! With a team of 2 people for Linux support, we do what we can. But we are focused on select distros due people power, time and a variety of other factors.

Appreciate the update.

5 Likes
8

Thanks for posting this.

I run into this today on Fedora 39 (13" AMD 7640). BIOS 3.3, 1TB SN850 SSD, DIY edition. Fully updated from the Fedora repos as of yesterday. Kernel = 6.5.6-300.fc39.x86_64. Full disk encryption via LUKS.

The only tweaks that I’ve made are to enable UMA_GAME_OPTIMIZED in the BIOS and to disable scatter/gather as a boot option (amdgpu.sg_display=0) to defend against the white screen corruption.

Today I booted up, started up a GNOME session and Firefox, checked some mail, and left to go do some other chores. It was plugged into an Anker Prime 737 100w GaN wall charger (which has been working fine) on the back right USB-C port. There was a Logitech G903 unifying receiver plugged into the USB-A port on the front right. Nothing was plugged into the USB-C or USB-A ports on the left side.

About two hours later, I came back to a black screen and the power button slowly flashing at me. It had gone into sleep mode on its own. Tapping keys, the power button, etc would wake not it up. The bottom was hot, as @Brod8362 reported, and the fan was not running. I tried closing the lid and plugging in an external monitor via USB-C to see if that would wake it up, but no dice.

Like @Brod8362, I also had to long-press the power button to forcefully stop it, and on reboot the fan was blasting.

Upon reboot, I checked Settings -> Power -> Automatic Suspend in GNOME Settings and it was set to automatically suspend after 15 minutes of inactivity even while plugged in. This is a new default that Fedora set starting with Fedora 38.

Note that changing it in the settings GUI doesn’t affect the behaviour of the login screen, which will continue to suspend after 15 minutes even while plugged in (per the linked post, gdm commands are required to affect that behaviour).

However, that doesn’t explain why it wouldn’t wake back up, or why the temperature would rise so much while suspended.

9

And now I’ve noticed that the default boot kernel is the oldest one, while the most recently installed kernel is 6.6.4-200.fc39.x86_64. Weird, I’m used to Fedora automatically booting into the most recent kernel. Guess I’ll switch that up and see if it resolves these issues.

Looks like the problem with the default kernel not being the most recently installed kernel is a known issue with a resolution.

10

Please do keep us posted. Thank you

1 Like
11

I have experienced the same behavior on 6.7.4-arch1-1.

12

Has this been tested with an earlier kernel? A release or two earlier for example? I’d also get this in front of other arch users who may have some similar experiences.

13

I have been suspending this machine multiple times every day since I got it and never experienced this issue. (1st batch AMD).

For the record I’m on a 13’ 7840U device, without any peripherals.

To be honest, if somebody experiences this I would expect them to report it.
It is fairly scary, “boiling hot” is an apt description.

14

As I am not experiencing this on Fedora, and I cannot repo it there. I wanted to better understand specific kernel releases as I feel like suspend isn’t happening at all.

Ideally we work to get this done before it starts heating up. This means do not put the laptop into sleep. Instead, run this. I have seen this before when suspend is not happening correctly. Following this below, you should not see the heat issue.

  • Disconnect everything from the laptop. No docks, attached peripherals, just power is left attached.

  • Let’s start by looking at what the outcome of this script happens to be.

sudo python3 amd_s2idle.py

I’d like to see the output of this specifically.

A friendly reminder, Arch is a community support distro. So ideally, we would test this by installing an officially supported distro and seeing if the behavior happens there.

If it does, we’d suggest opening a ticket, linking to this thread and we now suspect hardware.

If works correctly on a fully installed, fully updated install of Fedora, this is an Arch bug that would need to be reported.

15

I actually don’t usually let my machines sleep. When I’m not using them, I power it off. It’s a habit I got into a long time ago in college when I came home to a hot macbook (a core 2 duo pre-unibody) that had been cooking in my backpack for a while. After that I’ve never trusted sleep.

I can put my machine to sleep and it appears to be sleeping, but I haven’t left it long enough like that to see if it goes into egg cooker mode.

1 Like
16

My first actual computers were Atari 800’s and 286 PC-DOS PC’s.
No opportunity to sleep or hibernate on either of those.

I learned to save work, exit applications and shut them down when done.
Still do that today.

My FW13 Batch 1 11th Gen boots fast enough for me, and I do a variety of things, so I don’t want it to come up with other than a home screen.

17

Sorry, I should have responded much earlier that booting into the newer kernel on Fedora resolved the issue.

18

Fantastic! Delighted to hear this. Mark this one for Fedora.

Arch users, how is testing on linux-lts going for testing?

1 Like