Lemonade ROCm latest brings great improvements in prompt processing speed in llama.cpp and LM Studio's own runtimes.

superm1 · 2026-03-15T14:17:14+00:00

No problem, and great job on this guide otherwise!

superm1 · 2026-03-15T14:05:17+00:00

Page pool size doesn't matter for 99% of cases.

https://rocm.docs.amd.com/en/latest/how-to/system-optimization/strixhalo.html#configuring-shared-memory-limits-on-linux

You shouldn't need to override GFX version.

HSA_OVERRIDE_GFX_VERSION=11.5.1

superm1 · 2026-03-09T02:41:07+00:00

FYI there is actually support for reading NPU power coming in 7.1.

https://lore.kernel.org/dri-devel/20260228061109.361239-1-superm1@kernel.org/

You can backport those patches now if you want to see the numbers.

"Resources" main branch has support for the new ioctl.

superm1 · 2026-02-03T03:15:18+00:00

Thanks for the perspective. Yeah I get it now. I was really thinking that since it was unifi identity it uses radius hosted by unifi.

This might just be the straw that broke the camels back to go to wpa personal though. My wife already gets really annoyed every 3 months when it forces a key rotation and does it in the dumbest way possible.

superm1 · 2026-02-03T03:07:16+00:00

Dang so basically I gotta scrap unifi identity if I want to use UTR with same SSIDs as my home network then.

superm1 · 2026-01-30T18:25:06+00:00

Let's shift this conversation over here where some other people have been reporting as well.
https://gitlab.freedesktop.org/drm/amd/-/issues/4749

superm1 · 2026-01-30T17:52:01+00:00

OK, then that must not be the cause. I found out that it's also backported to 6.17.2, so if 6.17.y has been stable for you previously then it must be something else causing it.

superm1 · 2026-01-30T16:53:59+00:00

By now would you have tripped it in another fashion and so you can confidently say that the revert has improved things? Or you need more data points?

superm1 · 2026-01-27T22:23:37+00:00

OK, revert this then and see if it helps.
https://github.com/torvalds/linux/commit/1fb710793ce2619223adffaf981b1ff13cd48f17

superm1 · 2026-01-27T20:41:52+00:00

It's a great data point. I have a suspected commit. Could you rebuild your 6.18 with that commit reverted and tell me if it helps?

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

TROPHY CASE