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:
- if the power button is illuminated, hold it for 30 seconds so it goes dark
- charge on the right side until the indicator goes from orange to white
- disconnect charge cable
- wait 5+ minutes
- press power button and it boots
Initially I thought it could be battery charge related, but it can happen like this:
- resume from unresponsive state following guide above, so battery is at the 60% charge limit
- reboot machine a few minutes later
- 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:
- lid close, open
- suspend
- suspend then lid close open
- restarting
- power off then up
- all the above with video, microphone, etc on
- 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.