Framework Laptop 13 AMD 7040 becoming unresponsive

Which Linux distro are you using?
Fedora Linux 44 (Workstation Edition)

Which release version?
update every few days

Which kernel are you using?
Linux 7.0.4-200.fc44.x86_64

Which BIOS version are you using?
3.18

$ fwupdmgr update -v
(fwupdmgr:11761): GLib-GIO-DEBUG: 11:35:21.075: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
(fwupdmgr:11761): dconf-DEBUG: 11:35:21.075: watch_fast: "/system/proxy/" (establishing: 0, active: 0)
(fwupdmgr:11761): dconf-DEBUG: 11:35:21.076: watch_fast: "/system/proxy/http/" (establishing: 0, active: 0)
(fwupdmgr:11761): dconf-DEBUG: 11:35:21.076: watch_fast: "/system/proxy/https/" (establishing: 0, active: 0)
(fwupdmgr:11761): dconf-DEBUG: 11:35:21.076: watch_fast: "/system/proxy/ftp/" (establishing: 0, active: 0)
(fwupdmgr:11761): dconf-DEBUG: 11:35:21.076: watch_fast: "/system/proxy/socks/" (establishing: 0, active: 0)
(fwupdmgr:11761): GLib-GIO-DEBUG: 11:35:21.076: _g_io_module_get_default: Found default implementation gnome (GProxyResolverGnome) for ‘gio-proxy-resolver’
(fwupdmgr:11761): dconf-DEBUG: 11:35:21.077: watch_established: "/system/proxy/" (establishing: 1)
(fwupdmgr:11761): dconf-DEBUG: 11:35:21.077: watch_established: "/system/proxy/http/" (establishing: 1)
(fwupdmgr:11761): dconf-DEBUG: 11:35:21.077: watch_established: "/system/proxy/https/" (establishing: 1)
(fwupdmgr:11761): dconf-DEBUG: 11:35:21.077: watch_established: "/system/proxy/ftp/" (establishing: 1)
(fwupdmgr:11761): dconf-DEBUG: 11:35:21.077: watch_established: "/system/proxy/socks/" (establishing: 1)
(fwupdmgr:11761): Fwupd-DEBUG: 11:35:21.078: emitting ::status-changed() [idle]
(fwupdmgr:11761): FuMain-DEBUG: 11:35:21.084: current version is 01000334: 01000334=same
(fwupdmgr:11761): FuMain-DEBUG: 11:35:21.087: current version is 0.0.3.18: 0.0.3.18=same, 0.0.3.17=older, 0.0.3.16=older, 0.0.3.9=older, 0.0.3.7=older
(fwupdmgr:11761): FuMain-DEBUG: 11:35:21.090: current version is 2023: 2023=same
(fwupdmgr:11761): FuMain-DEBUG: 11:35:21.093: No releases found
Devices with the latest available firmware version:
 • Fingerprint Sensor
 • System Firmware
 • UEFI CA
 • UEFI dbx
Devices with no available firmware updates:
 • HDMI Expansion Card
 • KEK CA
 • Laptop Webcam Module (2nd Gen)
 • Option ROM UEFI CA
 • PIXA3854:00 093A:0274
 • SBAT
 • WD BLACK SN7100 1TB
 • Windows UEFI CA
 • frame.work-LaptopAMDDB
 • frame.work-LaptopAMDKEK

Which Framework Laptop 13 model are you using? (AMD Ryzen™ AI 300 Series, AMD Ryzen™ 7040 Series, Intel® Core™ Ultra Series 1, 13th Gen Intel® Core™ , 12th Gen Intel® Core™, 11th Gen Intel® Core™)
AMD 7040
AMD Ryzen™ 5 7640U w/ Radeon™ 760M Graphics × 12

Port Layout:
left monitor; usb-c
left trackpad; micro sd
right monitor; hdmi
right trackpad; usb-c
I have not tried switching the adapter layout.


My laptop (ordered in December 2025) over the past few months has increasingly been unresponsive. In this unresponsive state the screen is black, no audio/fan, no keyboard or power response, and while unresponsive it only charges via the right side, not the left side.

Sometimes it becomes unresponsive while I am using the computer, however it is typically unresponsive like this nearly every single time now it tries to resume from sleep or suspend, or even when trying to power back on after a reboot.

If it was properly asleep/suspended, whatever state it is when the power button has no light, then the light remains dark in this unresponsive state.

If it was in the state where the power button slowly blinks/glows/fades, then the power button will go dark and it enters this unresponsive phase.

If the power button was illuminated at the time of it going unresponsive, such as when it happened while using or while rebooting, then the power button will remain lit in the unresponsive phase.

I have found the following steps reliably get out of this unresponsive phase, but it is time consuming:

  1. if the power button is illuminated, hold it for 30 seconds so it goes dark
  2. charge on the right side until the indicator goes from orange to white
  3. disconnect charge cable
  4. wait 5+ minutes
  5. press power button and it boots

Initially I thought it could be battery charge related, but it can happen like this:

  1. resume from unresponsive state following guide above, so battery is at the 60% charge limit
  2. reboot machine a few minutes later
  3. same deal, but battery now only takes a minute or two to charge back up, then have to wait the 5+ minutes

Just tried reproducing the unresponsiveness after getting it working this morning, after it became unresponsive during the reboot to update to kernel Linux 7.0.6-200.fc44.x86_64, and couldn’t reproduce, tried:

  1. lid close, open
  2. suspend
  3. suspend then lid close open
  4. restarting
  5. power off then up
  6. all the above with video, microphone, etc on
  7. no luck reproducing…
    Maybe this morning’s kernel update finally fixed it, or maybe I just haven’t figured out what reliably causes it yet.

Only error in sudo dmesg is this, which is upon every boot:

[    2.024336] ucsi_acpi USBC000:00: unknown error 0
[    2.024349] ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)

All photos and videos of debugging here:

I’ve been going back and forth with support, but the email nature of that makes debugging difficult, so consolidating everything here.

Do you have, or can make an, live USB?, it sounds like it could be software related.

Support will probably ask you to upgrade the BIOS, unless 3.18 is the latest version on 7040, it’s not on the 1100G0 series.

I’m not sure it is necessarily software, as once it becomes unresponsive, there is no pedestrian way to make it responsive to even post to bios.

Maybe software induced, however it is sporadic and I haven’t found any reliable way to induce it. That said, it seems to happen every morning when I go to use the laptop.

If I can find a way to reliably induce it, then yeah, a live os would be a good way to distinguish further.

Framework support have given me numerous hardware things to try - unplugging certain things, reconnecting certain things. I still have to go through them - will now carry the framework screwdriver with me in the mornings.

You said you have charge limit at 60% is that correct? If so consider removing it and charge the battery up to 100% once to recalibrate the battery. I might be wrong about the recalibration sequence, and if you have the 61wh battery I wouldn’t let it stay charging for more then an hour at 99%.

@Charlie_6 has written a lot about the many issues with [the] 61wh battery if you are curious.

I don’t think it’s related to the battery I suggest adding amdgpu.dcdebugmask=0x10 to GRUB_CMDLINE_LINUX=

1 Like

Interestingly, after updating to kernel Linux 7.0.6-200.fc44.x86_64 the unresponsive problem hasn’t occurred, however neither left side port functions anymore (same expansion cards work on the right side). Perhaps the kernel update is coincidental.

Framework support have said it’s a faulty board and are doing a replacement.

Try updating the firmware on the

WD BLACK SN7100 1TB

There have been reports of it causing stability problems that the latest firmware fixes.

There is a windows sandisk firmware upgrade method, and also a manual linux update method.

Do a backup of your valuable files before the firmware update.