Framework 13 AMD (Ryzen AI 7 350) randomly freezing, kernel panics, Fedora Live also freezes

Which Linux distro are you using? arch linux (omarchy)

Which release version? omarchy 3.8.2

Which kernel are you using? 7.09-arch2-1

Which BIOS version are you using? 3.05

Which Framework Laptop 13 model are you using? AMD Ryzen™ AI 300 Series

Hello. everyone. I’m trying to figure out whether I’m dealing with a hardware issue, firmware issue, or something Linux-specific.

My Framework 13 has started randomly freezing and kernel panicking under Linux. It can happen during boot, at the login screen, shortly after login, or during normal use. One panic happened roughly 2 seconds after boot. I’ve seen messages like Fatal exception in interrupt and General protection fault, and some crashes show graphical
corruption.

Patterns I’ve noticed:

  • The internal display path seems much less reliable. The machine is only somewhat stable when using an external
    monitor with the laptop lid closed.
  • External-monitor-only is not a complete fix. It still freezes during graphics/video-heavy workloads, especially
    YouTube, Google Meet, or webcam usage.
  • Some failures include obvious graphical corruption.

Things I’ve already tried:

  • Reseated RAM
  • Moved RAM to the other slot
  • Loaded BIOS defaults
  • Tested both the regular Arch kernel and linux-lts
  • Tested outside my installed system with a Fedora Workstation Live USB

None of those changed the behavior.

I also ran MemTest86. It detected the hardware correctly, completed multiple tests, got through the Hammer Test, reached Pass 4, and reported 0 errors. The machine was able to sit under that load for close to an hour without freezing or rebooting.

To rule out my Arch/Omarchy install, I created a Fedora Workstation Live USB. That reproduced problems immediately. Depending on the boot attempt, Fedora would:

  • Show graphical corruption during boot
  • Freeze at the Fedora splash screen
  • Freeze while displaying Booting a command list
  • Freeze before reaching the desktop

I never managed to get a stable Fedora desktop running.

So at this point the issue reproduces on:

  • Arch
  • Arch linux-lts
  • Fedora Workstation Live USB

But MemTest86 reports no memory errors.

Some relevant Arch journal excerpts:

2026-06-09 11:56:39 kernel: Oops: general protection fault, kernel NULL pointer dereference 0x0
2026-06-09 11:56:39 kernel: CPU: 7 UID: 1000 PID: 1461 Comm: Hyprland Not tainted 7.0.9-arch2-1
2026-06-09 11:56:39 kernel: Hardware name: Framework Laptop 13 (AMD Ryzen AI 300 Series)/FRANMGCP07, BIOS 03.05
10/30/2025
2026-06-09 11:56:39 kernel: RIP: 0010:dm_atomic_get_state+0x38/0x40 [amdgpu]
2026-06-09 11:56:39 kernel: Call Trace:
2026-06-09 11:56:39 kernel:  pre_validate_dsc+0xcd/0x510 [amdgpu]
2026-06-09 11:56:39 kernel:  amdgpu_dm_atomic_check+0xd59/0x2170 [amdgpu]
2026-06-09 11:56:39 kernel:  drm_atomic_check_only+0x5c4/0x9f0
2026-06-09 11:56:39 kernel:  drm_atomic_nonblocking_commit+0x17/0x70
2026-06-09 11:56:39 kernel:  drm_mode_atomic_ioctl+0xb58/0xdb0

Another crash from the same day:

2026-06-09 12:28:25 kernel: Oops: general protection fault, maybe for address 0xffff8e6683040ca0
2026-06-09 12:28:25 kernel: CPU: 7 UID: 0 PID: 816 Comm: (udev-worker) Not tainted 7.0.9-arch2-1
2026-06-09 12:28:25 kernel: Hardware name: Framework Laptop 13 (AMD Ryzen AI 300 Series)/FRANMGCP07, BIOS 03.05
10/30/2025
2026-06-09 12:28:25 kernel: RIP: 0010:vma_interval_tree_remove+0xeb/0x300
2026-06-09 12:28:25 kernel: Call Trace:
2026-06-09 12:28:25 kernel:  unlink_file_vma_batch_add+0x7d/0xd0
2026-06-09 12:28:25 kernel:  free_pgtables+0x111/0x240
2026-06-09 12:28:25 kernel:  exit_mmap+0x26b/0x450
2026-06-09 12:28:25 kernel:  do_exit+0x2b1/0xbc0
2026-06-09 12:28:25 kernel: Fixing recursive fault but reboot is needed!

There was also one failed suspend/resume sequence:

2026-06-09 13:17:40 kernel: usb 7-1: USB disconnect, device number 2
2026-06-09 13:17:40 kernel: [drm] DM_MST: stopping TM
2026-06-09 13:17:40 systemd-logind: Suspending...
2026-06-09 13:17:41 systemd-sleep: Performing sleep operation 'suspend'...

After that, the next successful boot was much later, and the journal showed an unclean shutdown:

systemd-journald: system.journal corrupted or uncleanly shut down, renaming and replacing
systemd-journald: user-1000.journal corrupted or uncleanly shut down, renaming and replacing

The current connector state while booted externally still shows the internal panel detected:

card1-eDP-1/status: connected
card1-DP-12/status: connected

Has anyone with a Framework 13 AMD, especially a Ryzen AI 7 350 / Radeon 860M system, seen anything similar? I’m
trying to understand whether this points more toward hardware, firmware/BIOS, AMDGPU/kernel support, or something
else.

I’ve attached a picture of one of the kernel panics, on fedora live USB. I can get more pictures or logs if needed.

Since this reproduces on both your installed Arch setup and a Fedora live USB, I would treat it as not just an Omarchy config problem. The amdgpu trace plus internal-panel/graphics corruption pattern is worth sending to Framework support with the panic photo and the journal snippets. As a short diagnostic, you could try one boot with `amdgpu.dc=0` or `nomodeset` just to see whether avoiding the normal display stack changes the failure mode; I would not consider either a real fix. If you have two RAM sticks, also test one stick at a time even though MemTest86 passed, because random kernel faults can still be slot/module-sensitive.

I tried booting with nomodeset as requested. With nomodeset, I was able to boot using only the laptop panel, with no external screen. I could use the computer for about 30 minutes, but then it crashed again. After that, subsequent boots under the same nomodeset conditions failed.

Without nomodeset, the laptop panel usually does not even get me to the password prompt.

More generally, I reproduced the issue on my installed Arch setup, linux-lts, and a Fedora Live USB, so I agree this does not look Omarchy-specific anymore.

I have captured pstore/journal logs showing AMDGPU/display-related errors, eDP/EDID errors for the internal panel, and kernel panics/general protection faults.

The most reliable setup so far is external-screen-only. To do that, I added video=eDP-1:d to the kernel command line to disable the internal panel, then booted with the external display connected. In that setup I can boot fairly reliably, but it can still freeze during video/graphics-heavy use, especially Google Meet, webcam, or YouTube.

I also tried the common AMDGPU PSR workaround (amdgpu.dcdebugmask=0x10) and later tried amdgpu.dcdebugmask=0x14. Neither clearly fixed the issue.

I only have one 32GB RAM stick. I reseated it and also tried the other slot. MemTest86 completed multiple tests with 0 errors.

Hey @Robin_Gagnon Give our support a shout. Our support and Linux teams would be happy to see if they can help out here!

1 Like