Fedora 44 now reboots randomly after firmware update

Framework Laptop 16
,
1

I have updated the bios 2 days ago and have had 2 sudden reboots of my system with no warning or crash report after. I am also using an anker dockstation if that might be a source if issues. Below is a diagnostic report generated by claude to give as much info as possible.

Framework Laptop 16 — Unexpected Hard Reset After Resume from Suspend

Date of incident: 2026-05-01, 11:58 EDT (local) / America/New_York

Report generated: 2026-05-01 12:10 EDT

System

| | |

|—|—|

| Vendor | Framework |

| Product | Laptop 16 (AMD Ryzen 7040 Series) |

| Board | FRANMZCP07, rev A7 |

| BIOS | INSYDE Corp. 04.04, dated 2026-03-23 |

| CPU | AMD Ryzen 7 7840HS w/ Radeon 780M Graphics (8c/16t) |

| Memory | 2/2 slots populated (see system-info.log) |

| OS | Fedora Linux 44 Workstation |

| Kernel | 6.19.14-300.fc44.x86_64 |

| Secure Boot | Disabled |

| Disk | NVMe, root on LUKS+Btrfs |

Full details: system-info.log

Summary

The laptop hard-reset without warning approximately **93 seconds after resuming from

s2idle (modern standby) suspend**. There was no clean shutdown sequence, no kernel

panic captured to persistent storage, no MCE/thermal/watchdog message, and no

user-initiated reboot. The system journal cuts off mid-line in the middle of routine

Docker Desktop API polling, and the next entry is the next boot’s kernel banner.

This is consistent with a firmware-level / hardware reset (power rail collapse,

SoC hang followed by HW watchdog reset, or platform firmware fault) rather than a

Linux kernel panic.

It appears to be the second occurrence. last shows a prior unclean reboot on

2026-03-18 (“crash” marker — last only emits this when the previous boot has no

shutdown record).

Timeline (2026-05-01)

| Time (EDT) | Event |

|—|—|

| 10:49:08 | User initiates suspend; PM: suspend entry (s2idle) |

| 11:56:39 | Resume from suspend (~67 minutes asleep). PM: resume devices took 1.516 seconds then PM: suspend exit |

| 11:56:42–43 | Wi-Fi (wlp4s0) re-associates successfully |

| 11:56:44 | Bluetooth peripherals re-attach (Logitech MX Vertical) |

| 11:58:00–12 | Docker Desktop polls container stats every ~250 ms (normal idle behavior) |

| 11:58:12.265 | Last journal entry — log terminates mid-message |

| 11:59:23 | Fresh kernel boot; system back up |

Gap between last log line and next boot kernel banner: ~71 seconds (consistent

with POST/firmware time on this platform).

Detail: journal-final-seconds.log

Why this looks like a hardware/firmware reset, not a kernel issue

1. Journal terminates without any shutdown markers.

There is no systemd[1]: Reached target shutdown.target, no

systemd-journald[...]: Journal stopped, no reboot: or Power down message —

the log simply stops mid-Docker-Desktop output. A clean reboot or `systemctl

reboot` would produce dozens of teardown messages.

**2. No kernel panic, oops, BUG, MCE, or watchdog event in the seconds preceding

the cutoff.**

Filtered set of all kernel warnings from the previous boot (only firmware/thermal

warnings emitted at boot time, none near the crash):

kernel-warnings-prev-boot.log

3. Persistent kernel-message store is empty across the reboot.

pstore-contents.log

A software panic that the kernel had time to handle would normally land here.

4. The crash followed a resume from s2idle. Last events before the crash were

post-resume device re-init (Wi-Fi, Bluetooth, GPU SMU resume, Docker Desktop’s

QEMU/KVM VM resuming). Filtered events:

suspend-resume-events-prev-boot.log

5. This is recurring. From last:


reboot system boot 6.19.14-300.fc4* Fri May 1 11:59 still running ← this incident

reboot system boot 6.19.14-300.fc4* Thu Apr 30 10:56 ← previous boot

...

reboot system boot 6.19.8-200.fc43* Wed Mar 18 13:49 - crash (1+09:36) ← prior unclean reset

(The Apr 28 cluster is not related — those are clean shutdowns from a kernel

upgrade sequence, visible as paired shutdown/reboot lines in

boot-history.log.)

Notable firmware-reported issues at boot (probably unrelated, but flagging)


ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000)

ACPI: thermal: [Firmware Bug]: No valid trip points!

amdgpu 0000:03:00.0: amdgpu: SMU driver if version not matched

amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes

The thermal “Firmware Bug” messages mean the kernel sees no valid trip points from

ACPI for at least two thermal zones. If a true thermal runaway occurred,

this configuration would not log it before reset.

What was running at the time of the crash

  • GNOME Shell desktop session (Wayland)

  • Docker Desktop with a Linuxkit VM under QEMU/KVM:

-cpu host -machine q35 -m 8092 -smp 16 (8 GB, 16 vCPUs)

  • 5 active containers being stat-polled every ~250 ms

  • Visual Studio Code with Pylance extension

  • Firefox

No unusual workload — system had just resumed and was idle.

Reproduction frequency

Two confirmed unclean resets observed (2026-03-18 and 2026-05-01). Both followed

similar usage patterns (laptop closed/suspended, then resumed). Insufficient data

to confirm s2idle as the deterministic trigger, but it correlates strongly with

the May 1 event.

1 Like
2

I have no problems running the latest version.
I am no expert in firmware, but did you try to reinstall the update? At least that is what I would do.
Since you are on Linux, you can use the official Firmware app from fwupd’s lead developer.
Just make sure you unplug everything from the computer’s ports except the direct-to-wall charger (no dock in between).

1 Like