The Linux Thread - The Autist's OS of Choice

[dec05eba]

Another day, another amd gpu driver bug:

amdgpu: Dumping IP State
amdgpu: Dumping IP State Completed
amdgpu: [drm] AMDGPU device coredump file has been created
amdgpu: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
amdgpu: ring gfx_0.0.0 timeout, signaled seq=5529, emitted seq=5532
amdgpu:  Process gpu-screen-reco pid 3608 thread gpu-screen:cs0 pid 3609
amdgpu: Starting gfx_0.0.0 ring reset
amdgpu: Ring gfx_0.0.0 reset succeeded
[drm] device wedged, but recovered through reset
amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:7 pasid:32780)
amdgpu:  Process gpu-screen-reco pid 5165 thread gpu-screen:cs0 pid 5166
amdgpu:   in page starting at address 0x0000800100d84000 from client 10
amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00701031
amdgpu:      Faulty UTCL2 client ID: TCP (0x8)
amdgpu:      MORE_FAULTS: 0x1
amdgpu:      WALKER_ERROR: 0x0
amdgpu:      PERMISSION_FAULTS: 0x3
amdgpu:      MAPPING_ERROR: 0x0
amdgpu:      RW: 0x0

I'll buy an nvidia gpu next

 

[DavidS877]

Another day, another amd gpu driver bug:
...
I'll buy an nvidia gpu next

My laptop has both. There was a significant period when the AMD side was crap, silent full system hangs. Worked fine when I got it, then apparently a bunch of bugs appeared and it's finally stable again, more or less, with the newest kernel/firmware/etc.

 

[Dread First]

Another day, another amd gpu driver bug:

amdgpu: Dumping IP State
amdgpu: Dumping IP State Completed
amdgpu: [drm] AMDGPU device coredump file has been created
amdgpu: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
amdgpu: ring gfx_0.0.0 timeout, signaled seq=5529, emitted seq=5532
amdgpu:  Process gpu-screen-reco pid 3608 thread gpu-screen:cs0 pid 3609
amdgpu: Starting gfx_0.0.0 ring reset
amdgpu: Ring gfx_0.0.0 reset succeeded
[drm] device wedged, but recovered through reset
amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:7 pasid:32780)
amdgpu:  Process gpu-screen-reco pid 5165 thread gpu-screen:cs0 pid 5166
amdgpu:   in page starting at address 0x0000800100d84000 from client 10
amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00701031
amdgpu:      Faulty UTCL2 client ID: TCP (0x8)
amdgpu:      MORE_FAULTS: 0x1
amdgpu:      WALKER_ERROR: 0x0
amdgpu:      PERMISSION_FAULTS: 0x3
amdgpu:      MAPPING_ERROR: 0x0
amdgpu:      RW: 0x0

I'll buy an nvidia gpu next

Oof. That’s rough buddy. What are you running? Is your kernel and Mesa up to date?

 

[ProudSkibidiTolietAryan]

Remember when I said "Some things between the malta board and this random board are mismatched and expect different stuff" Well that applies to IO.. So no matter what I attach it will not properly mount or even acknologe that a disk exists. But hey I mean this is further than I thought id EVER get. But BELIEVE me I spent alot of time

I have a hell of story to tell you guys but sadly it has not reached the conclusion JUST yet.
In the meantime I plan to get that Sony kernel source.

So stay tuned for that.

 

[blackshirt]

Which distro do you guys think is least infested with tranny bullshit? My money's split three ways between Gentoo, Guix and Artix. Something about source compilation or declarative systems makes me think that trannies are less likely to invest the time to make them shine in comparison to a quick and dirty niri + arch rice they can spam /g/ with. Anything that shills systemd + wayland seems to be tranny central.

Not a distro but honorable mention to the suckless team. Been using dwm for a decade.

 

[Dread First]

Which distro do you guys think is least infested with tranny bullshit? My money's split three ways between Gentoo, Guix and Artix. Something about source compilation or declarative systems makes me think that trannies are less likely to invest the time to make them shine in comparison to a quick and dirty niri + arch rice they can spam /g/ with. Anything that shills systemd + wayland seems to be tranny central.

Artix > Guix System > Gentoo > ??? > Poetterware slop that make up 90% of distros today

 

[dec05eba]

Oof. That’s rough buddy. What are you running? Is your kernel and Mesa up to date?

Arch linux, latest mesa (25.3.2). Such bugs are very common on amd. The moment you try to do anything unusual to optimize a program the driver shits itself.
I posted this before but here is another one I had some time ago:

 

[Betonhaus]

Arch linux, latest mesa (25.3.2). Such bugs are very common on amd. The moment you try to do anything unusual to optimize a program the driver shits itself.
I posted this before but here is another one I had some time ago:
View attachment 8324594

that's a big qr code

 

[⠠⠠⠅⠑⠋⠋⠁⠇⠎ ⠠⠠⠊⠎ ⠠⠠⠁ ⠠⠠⠋⠁⠛]

Arch linux, latest mesa (25.3.2). Such bugs are very common on amd. The moment you try to do anything unusual to optimize a program the driver shits itself.
I posted this before but here is another one I had some time ago:
View attachment 8324594

Interesting. When I scan the QR code, the kernel panic references an issue with webcam drivers, possibly?

RoboNuggie is my preferred outlet for BSD content. There's something oddly comforting and vaguely nostalgic about an elderly British sysadmin going over the fundamentals of FreeBSD and the latest goings-on within the BSD sphere.

I enjoyed his video on the 'yes' command.

FACT: Anyone who complains about Powershell not following the Unix Philosophy and being bloated is a hypocrite if they don't personally patch out any 'yes' flag (like -y on 'apt-get', 'yum', etc) out of any command which provides them. Just pipe 'yes' into it you fucking niggers, you degenerate traitors to the Unix Philosophy.

 

[dec05eba]

Interesting. When I scan the QR code, the kernel panic references an issue with webcam drivers, possibly?

It's an issue related to webcam + amd yes. My program tries to map the webcam dmabuf directly in opengl with an unusual format. I think there is an incorrect buffer check in the amd driver because of the format of the webcam data (yuyv) vs the requested map format (xrgb8888 or rg8. I have an older nvidia gpu that this works on. Intel also has similar issues, when I try to map a dmabuf from an nvidia gpu in intel it freezes the computer. Doing it the other way around with nvidia works. Nvidia driver stack is way more robust than the mesa amd/intel stack.

 

[Lard Shart]

How people like this stay employed is beyond me.

It's Microsoft. Izzat is all that matters there. Shit talking C and praising Rust is positive izzat regardless of practicality, as it's universally agreed upon that Rust gud C bad (by globohomo, tech troons, and neophiles).

 

[Voloromir of bad Yuristan]

Another day, another amd gpu driver bug:

I've been basically stuck in playing sdr games lately because if I use either proton-ge or proton-cachyos, my computer would crash completely, I tried to solve the bug about the gpu being run at over the specs but it still consistently crashes thanks to the bugs, it doesn't happen on my intel arc laptop.
Personally had nvidia laptops for a lot of time (not now, tho), and usually if I ever had any issues with the computer, they were all related to the nvidia driver, every single time, and in the end I always ended up running my computer with the mux switch set for nvidia only because if I had the built-in active, doing almost anything becomes a chore.

 

[acid_ra1n]

what is the coolest terminal emulator
bonus points for being cross platform (even though i only use linux)

 

[Dread First]

what is the coolest terminal emulator
bonus points for being cross platform (even though i only use linux)

xterm. All other terminal emulators are standing on the shoulders of xterm.

 

[acid_ra1n]

Arch linux, latest mesa (25.3.2). Such bugs are very common on amd. The moment you try to do anything unusual to optimize a program the driver shits itself.
I posted this before but here is another one I had some time ago:
View attachment 8324594

as much as people like to rave about amd being open source
they have reasons for it but community driver maintainers are not one of them
amd is the sole contributor to the amd drivers, despite them being source available
we're really just lucky amd puts so much effort into supporting their legacy customers

 

[Trans Fat 41g]

XTerm is a venerable terminal emulator but I have to hand it over to Suckless' ST because it's a really good baseline for multiplexers like DVTM and session managers like Abduco.

 

[Dread First]

as much as people like to rant and rave about amd being open source
they have reasons for it but community driver maintainers are not one of them
amd is the sole contributor to the amd drivers, despite them being source available
we're really just lucky amd puts so much effort into supporting their legacy customers

In absolute fairness, it's AMD maintaining the amdgpu stack but also the Mesa developers contributing massively to OpenGL/OpenCL/Vulkan support for AMD cards thanks to all the documentation AMD publicised over the last 10 years. Just putting this out there: my previous PC, now a home server, has an RX Vega 64 slotted in it since 2019. On Windows? Shit's basically EOL; AMD Adrenalin don't make feature updates no more, it's slated to go kaput fairly soon. On Linux? amdgpu still keeps pushing out new feature updates, alongside incremental improvements to the architecture. Even on the outdated Mesa and amdgpu that Linux Mint ships with, my Vega's basically able to go toe to toe with RDNA cards (with caveats; strict 1920x1080p, dual monitors capped @ 60Hz with a 5ms response time, RDNA outperforms Vega in power draw and efficiency, you get my drift). Vega's even got (software) ray tracing under amdgpu, but completely lacks such an option under Windows, and the same is true for GCN 1.0/1.1 cards once version 6.19 of the Linux kernel drops and cards like the R9 290 and the HD 7970 can finally enjoy proper amdgpu support.

 

[prollyanotherlurker]

what is the coolest terminal emulator
bonus points for being cross platform (even though i only use linux)

Depends what you mean by coolest.

Now days for what you are asking about the answer is kitty. It's definitely on apple, and linux, along with any of the other unix's. I think their might be a windows version too. It has a ton of features. A lot of which were copied by the other modern terminals (not that there is anything wrong with them using the same concepts kitty came up with).

But otherwise I've always been partial to the suckless tools. St is nice if you are willing to patch it, I think a patched st is better than xterm, I definitely prefer it. I don't know if it will run on apple (technically I think it should if you adjust the config.mk to build on apple), but I don't use anything it wouldn't run just fine on. Obviously like any of the suckless tools it's minimal, so you will need to configure it to do the things you want it to do.

 

[acid_ra1n]

In absolute fairness, it's AMD maintaining the amdgpu stack but also the Mesa developers contributing massively to OpenGL/OpenCL/Vulkan support for AMD cards thanks to all the documentation AMD publicised over the last 10 years. Just putting this out there: my previous PC, now a home server, has an RX Vega 64 slotted in it since 2019. On Windows? Shit's basically EOL; AMD Adrenalin don't make feature updates no more, it's slated to go kaput fairly soon. On Linux? amdgpu still keeps pushing out new feature updates, alongside incremental improvements to the architecture. Even on the outdated Mesa and amdgpu that Linux Mint ships with, my Vega's basically able to go toe to toe with RDNA cards (with caveats; strict 1920x1080p, dual monitors capped @ 60Hz with a 5ms response time, RDNA outperforms Vega in power draw and efficiency, you get my drift). Vega's even got (software) ray tracing under amdgpu, but completely lacks such an option under Windows, and the same is true for GCN 1.0/1.1 cards once version 6.19 of the Linux kernel drops and cards like the R9 290 and the HD 7970 can finally enjoy proper amdgpu support.

oh yeah vega and radeon pro were really fucking nice cards that got like no support
sadly amd has put rnda2 and under on security updates only so they get versions and u dont have to install an older driver but the actual support should be over by this point
most of my machines r so old that they no longer get mesa updates and that makes linux a huge headache for gaming for me

 

[Dread First]

oh yeah vega and radeon pro were really fucking nice cards that got like no support

It wasn't the fact that there was "no" support for them; it was the fact that what little support for them existed when they were current was fucking awful. On Windows, I was doing all sorts of undervolt/overclock shenanigans to get better performance out of my Vega 64. Mind you: I got this thing for $400 in 2019 and that was during a time when RX 580s were still retailing for $350. Polaris cards can get a bit fucky-wucky with the thermals, but Vega took it to a whole new level. On a fundamental hardware level, Vega 64s had way too much going on and not enough power efficiency to balance them out.

On Linux, the difference from Windows was like night and day. amdgpu wasn't drawing an obscene amount of power and making the fan sound like a wind turbine on this Vega 64 (a reference Sapphire Vega 64 with the shitty single blower fan). I can fire up RuneScape 3, Dark Souls III, Persona 4 Golden, or emulators running at 4x rendering resolution with the Vulkan backend and xBRZ texture filters without seeing the power LEDs going up to half and the blower fan aggressively whirring up. For all of amdgpu's faults (and there are many), it really must be said that the jump from Windows to Linux was made all the easier because I didn't have to wrestler with the drivers so much.

sadly amd has put rnda2 and under on security updates only so they get versions and u dont have to install an older driver but the actual support should be over by this point

I mean... that blows, but I don't think you properly understand just how monumental the shift toward amdgpu was from the dichotomy of xf86-video-ati with good 2D acceleration, bad 3D acceleration, good multimonitor support, and good power management vs. AMD Catalyst (formerly FGLRX; Fire GL and Radeon for X) having piss-poor everything else but "better" 3D acceleration. There was a time for more than a decade where NVIDIA's binary driver was actually the "gold standard" for Linux GPU support because the drivers were proprietary, but everything actually worked properly. Now? The situation's been comically inverted where AMD now has the best driver support on Linux, older cards from GCN-onward are still getting some modicum of support, bugfixes, architectural improvements, and so on despite the general lack of feature updates.

most of my machines r so old that they no longer get mesa updates and that makes linux a huge headache for gaming for me

I mean... how old we talking here? Surely you can't be running an FX-8350 and an HD 7970 with xf86-video-ati, right?