AMDGPU must be buggy

At least on this laptop with Debian 13, two freezes today. Maybe PyCharm is triggering a AMDGPU bug.

I disabled the integrated GPU, in case it’s the one crashing. I’m not looking at the logs again, to see if it says, it might not.

I used driverctl, basically set an override to vfio-pci. That is the easiest way to “disable” the integrated GPU on this laptop, I doubt I can in the shitty bios.

Desktop has a 6xxx series AMDGPU too, my eGPU on laptop is, and it almost never freezes. But it’s also running openSUSE Tumbleweed.

But some people are getting these timeout flip errors with Arch Linux, so using a rolling distro might not do any good.

And I forgot both times to try getting into a TTY. Seemed completely frozen, so just forced it off both times.

At least any spyware I’m unaware of, can’t easily run 24/7 with a buggy AMDGPU.

Update

amdgpu 0000:6a:00.0: [drm] *ERROR* [CRTC:85:crtc-0] flip_done timed out

And it’s the eGPU. So disabling the internal GPU didn’t fix anything. And good luck getting in a TTY as well if the above happens, and you disabled the iGPU.

Using openSUSE Tumbleweed might not fix anything, if you search for that, you’ll find results on the openSUSE forum as well.

So I guess the GPU being the same series as my desktop GPU doesn’t matter.

Might be a hardware problem as well, so maybe the GPU is defective. Nice.

Also, can be any hardware. But with an eGPU, is it the laptop or the eGPU? Could be the eGPU enclosure for all I know.

But good luck finding a eGPU enclosure. You can get a thing that you plug a GPU in, but it’s not enclosed. And I only want an enclosure, not with a video card.

I could replace the PSU in it, but no idea if that would fix anything. If it’s the PSU or enclosure, I’d rather just replace the entire thing.

But if I get a new enclosure or something, and it still happens, I just wasted money.

Four results on eBay for eGPU enclosure, when filtering with new only.

Would bad RAM cause AMDGPU to crap out?

Well, you can get a case for those eGPU things. Too lazy to fix printer and print a case. So I’d buy a case. And if the PSU in my eGPU enclosure will work with it, I can try using it first, and see if anything is fixed. Then replace the PSU if not. Then maybe run a memtest if not. Or ditch the laptop. The cheapest option, would be to ditch the laptop.

And good luck finding the EXP GDC TH5P4 from a US seller. I’m not paying Trump money directly. And that’s Thunderbolt 5, so if you find it, and you have no Thunderbolt 5, like me, well might not work anyways. I have USB4. Too lazy to lookup if Thunderbolt 5 is backwards compatible. Amazon might have that one, but don’t search for all of it, or on Amazon. Cause it’s called something else on Amazon, if it’s the same thing.

AOOSTAR AG02 not in stock from US warehouse, and no idea if you can get a case.

Maybe my dock is the issue as well.

Razer Core X V2 that’s for sell, but it’s Thunderbolt 5 and $350. So I guess the old one can’t be bought new anymore. What about refurbished from Razer? Even though Razer kind of sucks.

Their site says USB4, and even Thunderbolt 4. So might work. Not sure I want to spend $350 though.

No PSU, and they want $350. Well standard PSUs, so maybe you can find one cheap enough, but a good one will cost at least $100, maybe more now, thanks to the Trump tax.

They have a bundle for another almost $200. Which has a PSU, but not sure I want a Razer PSU for another $200.

Also, this enclosure I have, might not be compatible with my GPU. Probably older then the GPU.

And you probably need Windows to update firmware on it, and probably no firmware updates.

And might just be a AMDGPU problem, see here.

And disabling FreeSync could fix it as well. But you may have to do on monitor, guess in KDE isn’t enough. Also, what’s the point in a FreeSync monitor if I can’t use it? And didn’t work for one person anyways.

And for some people, “KWIN_DRM_NO_AMS=1” fixes it. And I just commented it out in /etc/environment. Now to reboot. Will that disable FreeSync? Might actually fix it though, considering it was already in /etc/environment, just commented out.

qdbus org.kde.KWin /KWin supportInformation | grep "Atomic Mode Setting"
qdbus: could not find a Qt installation of ''

So after I reboot, that command probably still won’t work, nice. How do I check if it’s disabled then?

qtchooser is useless, can’t even find version 6. Just run qtchooser -l, and 6 isn’t listed.

/usr/lib/qt6/bin/qdbus org.kde.KWin /KWin supportInformation | grep "Atomic Mode Setting"
Atomic Mode Setting on GPU 0: true

I guess that’s the correct way to run it in Debian. Cause the one in /usr/bin/ doesn’t work.

 /usr/lib/qt6/bin/qdbus org.kde.KWin /KWin supportInformation | grep "Atomic Mode Setting"
Atomic Mode Setting on GPU 0: false

Well, it’s disabled. Local WP wouldn’t open, tried opening more then once, then a bunch of processes that couldn’t be killed. Had to reboot again. And wouldn’t reboot, so had to force it off. Maybe disabling the iGPU was a bad idea.

And after rebooting again, it’s doing the weird thing it was doing in VanillaOS, which uses Gnome. Like the screen losing it’s signal for a second or something.

Maybe I should also disable adaptive sync, still set to automatic.

Maybe FreeSync is a spyware thing, only works in OSes with spyware, like Windows.

Disabled FreeSync on the monitor, and haven’t noticed the weird losing signal thing yet. Also disabled in KDE.

Guess I didn’t need a FreeSync 4k monitor. It does have a good picture. And a high refresh rate. But the GPU can’t even do 160 FPS on the highest game settings anyways.

Just did it again. Just not as often I guess. Might need something besides KDE and Gnome then.

Don’t think it was doing it with AMS enabled. So that means it’s related to ASM, and whatever Gnome uses that does the same thing.

Maybe I need KWIN_DRM_NO_DIRECT_SCANOUT=1 as well, it’s in the file commented out.

Might be Pycharm causing the weird issue now though. Might be using Java. Java isn’t that great.