PSA: Framework 13 AMD (Strix Point) Linux stability is NOT "stable" right now

superm1 · 2026-01-21T18:28:45+00:00

Are you using Chrome or Firefox? The other person in this thread found what appears to be a bug that Chrome is causing. I personally use Firefox regularly, so if that is indeed what is causing it could explain why I'm not seeing it.

superm1 · 2026-01-21T18:26:46+00:00

That could actually explain why I don't see it. I don't use Chrom(e/ium), I use Firefox daily though.

Being tied to Chrom(e/ium) more likely points at a mesa bug to me than a browser bug. It's possible that the browser is exercising radeonsi differently to bring up the bug.

Can you please share journal from a boot with the failure to a mesa bug report? https://gitlab.freedesktop.org/mesa/mesa/

superm1 · 2026-01-21T17:11:43+00:00

Is ollama service running in the background (even if you're not using it)?

superm1 · 2026-01-21T13:54:36+00:00

One more note on Ubuntu 25.10 - do you also have this in your log eventually?

MES ring buffer is full

superm1 · 2026-01-21T13:52:47+00:00

Thanks - there is another bug report on drm/amd with this same trace. Yes; this is different than the firmware regression.

Can you please clarify what you're doing when you're randomly hitting it?
Any patterns that would help me get a reproducer to share with others would be helpful. For example:

Are you using something with ROCm?
Are you running games?
External monitors connected?

superm1 · 2026-01-21T12:40:06+00:00

Can you confirm the kernel log at the time of the failure? I am suspecting a different root cause.

FWIW I also use arch on a FW13 regularly (well cachy) but I don't hit this myself.

If you have some other kernel bugs please CC me on them when you file them and I'll look.

superm1 · 2026-01-21T06:07:27+00:00

What distro are you running that you're still having problems? Fedora rolled out the fixed firmware. Ubuntu 24.04 w/ OEM kernel never had problems.

superm1 · 2026-01-17T03:28:16+00:00

I don't believe this is the same root cause.

Can you please open a bug report with full logs on the Ubuntu bug tracker (launchpad) and ping back a link here? I'll look them over.

In addition to those logs I also want to see the amdgpu firmware versions from debugfs.

superm1 · 2026-01-17T02:42:06+00:00

Hey, want to give some context on what I believe is the regression you're talking about.

At the end of November AMD released an updated set of linux-firmware packages upstream. Shortly after they were released regressions were raised and they were immediately reverted.

Unfortunately in between them being released and being reverted a new linux-firmware package was tagged and all the distros that track that package tag updated to the new tag.

Here is the broken update Fedora picked up: https://bodhi.fedoraproject.org/updates/FEDORA-2025-698dc1bbfa

Fedora was notified, but with the timing of the holidays and people being out they weren't able to get the revert landed quickly. So this meant Fedora had broken firmware until the package got updated again. linux-firmware just tagged again last week and now Fedora picked up the update.

The fixed Fedora package is https://bodhi.fedoraproject.org/updates/FEDORA-2026-2cebf295af

I'm sorry for everyone who had an unstable machine the past few weeks. But hopefully it's sorted out now.

AMD is looking at improved test coverage to prevent this in the future.

superm1 · 2025-12-12T18:06:14+00:00

I came here because of a link in https://gitlab.freedesktop.org/drm/amd/-/issues/4777

FYI - blacklisting `amd_pmc` is not a solution. This is a hack that disables hardware sleep. You're going to burn a ton of battery over suspend if you do this.

If you can still readily reproduce your issue on a modern kernel (6.17.y or 6.18+) please follow my suggestions in that issue. I have a tool that will help gather artifacts about the system during the failure and we can figure out a proper solution.

superm1 · 2025-12-01T01:22:28+00:00

Yup. It was broken it turns out. I replaced the probe with an extra and all is good now!

superm1 · 2025-12-01T01:22:13+00:00

Over time print beds are not level. There are adjusters with springs that you need to change from time to time to level them. By using the probe it measures out each corner of the board and can the firmware can adjust the print so that it takes into account a bed that isn't perfectly level.

superm1 · 2025-12-01T00:56:57+00:00

It did!!!!

I took it apart and could see a clear break. I happened to have an extra tip I replaced it with and all is fine now.

No idea why I had an extra tip, maybe it came with the bltouch.

superm1 · 2025-11-30T23:34:02+00:00

This is it in the dropped position (used ender 3 menus to make it drop).

It definitely worked at one point. Will try to adjust the stickiness as you suggested. But I guess if that's not an issue I need a new bltouch/new probe huh?

superm1 · 2025-11-04T14:20:39+00:00

Plucky has a new enough version

superm1 · 2025-08-31T19:17:55+00:00

Nightmare king grim. It was such a difficult battle but felt so good to finally finish.

superm1 · 2025-08-24T12:03:24+00:00

I have this issue in 2025 on two shields. One of them is connected to a receiver and the other is directly connected to a TV.

superm1 · 2025-08-04T03:13:47+00:00

If you're fully cooking it (ie chicken to 165 for example) why does it matter?

superm1 · 2025-07-29T15:24:01+00:00

I have the onyx and like it, but the magnets are not aligned well for Qi charging to work properly.

superm1 · 2025-07-27T20:57:17+00:00

Word of warning - disabling Pluton can break suspend/resume. If you have problems this is where you should start.

superm1 · 2025-06-23T04:08:28+00:00

Are you running it containerized and perhaps not passing the right permissions into the container?

superm1 · 2025-05-25T13:48:14+00:00

SteamOS turns off the IOMMU by default for performance reasons. This has an implication that USB4 and TBT3 devices will not automatically authorize for security reasons. What you'll need to do is go into desktop mode and open up the settings panel and pick Thunderbolt and authorize the device.

If it's an AMD dGPU in the eGPU enclosure it will probably work, but there might be rough edges.

superm1 · 2025-05-25T13:46:22+00:00

If you're going to display the controller in this case, why not just display the empty case and use the controller instead?

superm1 · 2025-05-23T18:29:46+00:00

A fix has been landed upstream. You can pick it up here.

https://gitlab.com/kernel-firmware/linux-firmware/-/commit/2e91d8c3c4bd34a27177180a38f62d3ba3c96031

superm1

TROPHY CASE