amdgpu ati radeon NetBSD-current

rvp

~ λ alacritty
libGL error: MESA-LOADER: failed to open radeonsi: /usr/pkg/lib/dri/radeonsi_dri.so: Undefined PLT symbol "amdgpu_query_video_caps_info" (symnum = 201) (search paths /usr/pkg/lib/dri, suffix _dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast: /usr/pkg/lib/dri/swrast_dri.so: Undefined PLT symbol "amdgpu_query_video_caps_info" (symnum = 201) (search paths /usr/pkg/lib/dri, suffix _dri)
libGL error: failed to load driver: swrast
Error: Error { raw_code: Some(167), raw_os_message: Some("GLXBadFBConfig"), kind: BadConfig }
~ λ

This indicates a mismatch between libdrm (where amdgpu_query_video_caps_info is implemented) and Mesa/dri. I don't know how you ended up in this mess--prolly due to the WIP package? Both Mesa/dri and libdrm are provided by the base Xorg package (unless you've skipped that entirely and gone with the modular Xorg package).

Uncommenting the debug options in the kernel config can push some class of bugs underground--like cockroaches...ie. doesn't mean they're "fixed". However,

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: DRM device has no render node (t=0.462674) [GFX1-]: glxtest: DRM device has no render node

Have you got the standard device files (with the correct perms.) in /dev/dri:

$ ls -l /dev/dri/
total 0
crw-rw----  1 root  wheel  180,   0 Feb 15  2024 card0
crw-rw----  1 root  wheel  180,   1 Feb 15  2024 card1
crw-rw----  1 root  wheel  180,   2 Feb 15  2024 card2
crw-rw----  1 root  wheel  180,   3 Feb 15  2024 card3
crw-rw----  1 root  wheel  180, 128 Jan 31  2024 renderD128
crw-rw----  1 root  wheel  180, 129 Jan 31  2024 renderD129
crw-rw----  1 root  wheel  180, 130 Jan 31  2024 renderD130
crw-rw----  1 root  wheel  180, 131 Jan 31  2024 renderD131
$

Create them using:

$ su -l
# cd /dev
# sh ./MAKEDEV drm0 drm1 drm2 drm3

Then file a PR with the dmesg and Xorg.0.log outputs if it still fails to work (after you get rid of the extra libdrm stuff).

pfr

rvp don't know how you ended up in this mess--prolly due to the WIP package?

Possible, but before installingwip/libdrm-dfbsd firefox was not usable as the screenshot illustrates.

rvp Both Mesa/dri and libdrm are provided by the base Xorg package (unless you've skipped that entirely and gone with the modular Xorg package).

I don't recall doing anything fancy with the install... Is there a way to check?

rvp ave you got the standard device files (with the correct perms.) in /dev/dri

Yep.

~ λ ls -l /dev/dri/
total 0
crw-rw----  1 root  wheel  180,   0 Jun 18 10:57 card0
crw-rw----  1 root  wheel  180,   1 Jun 18 10:57 card1
crw-rw----  1 root  wheel  180,   2 Jun 18 10:57 card2
crw-rw----  1 root  wheel  180,   3 Jun 18 10:57 card3
crw-rw----  1 root  wheel  180, 128 Jun 18 10:57 renderD128
crw-rw----  1 root  wheel  180, 129 Jun 18 10:57 renderD129
crw-rw----  1 root  wheel  180, 130 Jun 18 10:57 renderD130
crw-rw----  1 root  wheel  180, 131 Jun 18 10:57 renderD131

pfr

I'll add that I didn't notice that alacritty wouldn't launch until after I'd installed wip/libdrm-dfbsd in order to fix the firefox issue.

I could perhaps uninstall the wip/libdrm-dfbsd package and then see what other errors I get... however, I anticipate firefox and thunderbird being unusable again. You can see the errors produced by firefox in my comment's above.

rvp

pfr I could perhaps uninstall the wip/libdrm-dfbsd package

Yes.

As I said: this looks like a kernel bug. You should file a PR (after you've tried the modesetting driver--have you?); and until it's fixed you could just turn off GL rendering, as a workaround.

In ~/.xinitrc (or, ~/.xsession):

# for firefox
export MOZ_ACCELERATED=0
export MOZ_WEBRENDER=0

# for all MesaGL (see: https://docs.mesa3d.org/envvars.html)
export LIBGL_ALWAYS_SOFTWARE=true

Or, just go back to the wsfb Xorg driver (which works on top of the DRMKMS-provided framebuffer too) as a last resort.

pfr

rvp after you've tried the modesetting driver--have you?

That's what I am using now, yes.

rvp In ~/.xinitrc (or, ~/.xsession):

Similar to our other discussion, I'm curious to know if it is imperative that I use one of these and not ~/.profile? I have most other environment variables set in my ~/.profile

EDIT

Furthermore, I cannot seem to find where libdrm-dfbsd is installed or how to uninstall it?

bsduck

wip/libdrm-dfbsd

Does NetBSD import drivers from DragonFly BSD?

rvp

pfr Similar to our other discussion, I'm curious to know if it is imperative that I use one of these and not ~/.profile? I have most other environment variables set in my ~/.profile

If you run xdm/xenodm, then env. vars should be set in ~/.xsession. Any PATHs set in ~/.profile will only take effect inside xterms (and that too only if they're configured to run login shells). So, the PATH printed in an xterm will likely be different from the PATH seen by programs started by ~/.xsession (including the WM).

Check what sdorfehs's idea of PATH is using: Ctrl-a :exec echo $PATH > /tmp/path.txt

Might be a good idea to have a ~/.xsession like this:

#!/bin/sh
. ~/.environ        # suck-in env. vars
. ~/.xinitrc        #    "   ~/.xinitrc

Suck in ~/.environ the same way in ~/.profile too, and then all your env. vars. will be in one place (akin to ~/.bash_aliases for aliases and functions).

pfr Furthermore, I cannot seem to find where libdrm-dfbsd is installed or how to uninstall it?

Why doesn't

pkgin -y rm libdrm-dfbsd

work?

pfr

rvp Why doesn't
pkgin -y rm libdrm-dfbsd
work?

~ λ pkgin list | grep libdrm
libdrm-2.4.99        Userspace interface to kernel DRM services
~ λ pkg_info | grep libdrm
libdrm-2.4.99       Userspace interface to kernel DRM services
~ λ pkgin -y rm libdrm-dfbsd
no such installed package libdrm-dfbsd
no packages to delete

Looks like it isn't installed.. but one minute FF was transparent (see the screenshots above to prove it!) and then I went to my handy fzf-pkgsrc.sh script that some cool person wrote, and installed wip/libdrm-dfbsd. It installed without errors. To confirm this I rebooted and FF worked... so I don't know.

As for why I decided to install a dfbsd package, well I don't know exactly, I was just taking stabs in the dark and I'm an idiot I guess 😭

Anyhow, perhaps we can simply move on to the PR?

rvp if you run xdm/xenodm, then env. vars should be set in ~/.xsession

Yep, this is now how it's setup on my OpenBSD system. But on NetBSD (the current machine with the amdgpu) I just use startx and I no longer use sdorfehs on this system, I use exec dbus-run-session -- startlxqt.

So my question should have been more specific: Why would I put env. vars into my ~/.xinitrc over my ~/.profile in this case? -- I currently set everything in ~/.profile and everything appears to work as intended.

Cheers.

Disclaimer: Unrelated to the topic but, I couldn't just let it pass.

pfr on this system, I use exec dbus-run-session -- startlxqt

This line could wake-up unexpected bugs as the startlxqt script already calls dbus.

rvp

pfr ~

λ pkgin list | grep libdrm
libdrm-2.4.99        Userspace interface to kernel DRM services

So, the package is called libdrm instead of libdrm-dfbsd.

pfr Anyhow, perhaps we can simply move on to the PR?

Why only move? Rush into it! 😃

pfr So my question should have been more specific: Why would I put env. vars into my ~/.xinitrc over my ~/.profile in this case?

Either place is OK--for the most part--but, there's really no reason to set variables in ~/.profile which'll only be used inside an X session. Plus, there are a few variables like LANG=XXX.UTF-8 which could be set in console sessions, but then, programs (like lynx) don't display very well because NetBSD's console driver doesn't do UTF-8 (no fonts; no multi-byte input).

pfr

pin fixed, cheers.

pfr

rvp ok. Uninstalled librdm and set those vars so FF works (Alacritty too!) But, this happened...

Screen is half black:

However, if I take a screenshot it appears fine:

So, for now I'll leave this line commented out

# for all MesaGL (see: https://docs.mesa3d.org/envvars.html)
#export LIBGL_ALWAYS_SOFTWARE=true

FYI:
dmesg
Xorg.0.log

pfr

I hope reinstalling isn't the only option. If I have to though, It'll take me a bit to clean up my backups etc.

rvp

pfr I hope reinstalling isn't the only option.

No need, I think. But, keep an eye on this pull-up request. Wait a week or so after that's been closed, then update to the latest -STABLE. Recompile the kernel for amdgpu from the same source, and see if the fixes pulled up from -HEAD works.

pfr

rvp Looks like this ticket has been closed?
Sorry, I find these threads hard to follow. But by the looks of it Martin got it done, yes?

Also, kind of of topic but I wanted to know if I could keep the 1440p resolution while the system boots. Well, actually this is probably incorrect as you stated that the resolution doesn't change, but after a certain trigger the framebuffer just uses larger text? Nevertheless, is there a way to enforce it to use the smaller text? The benefit of this would be that I'd be able to read more of the boot log with it still on my screen before logging in. Also, I just prefer it. 🙂

rvp

pfr Looks like this ticket has been closed?

Looks like it.

pfr Nevertheless, is there a way to enforce it to use the smaller text?

Just comment-out the larger font, or do wsconsctl -dw font=Boldface as root

pfr Also, kind of of topic but I wanted to know if I could keep the 1440p resolution while the system boots. Well, actually this is probably incorrect as you stated that the resolution doesn't change, but after a certain trigger the framebuffer just uses larger text?

Console text is now consistent throughout the boot sequence. This took place somewhere in between Oct. 25 and Nov. 1

~> uname -a
NetBSD mybox 10.99.12 NetBSD 10.99.12 (GENERIC) #0: Fri Nov  1 09:22:26 UTC 2024  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

pfr

OK, upgraded my system to the latest daily build and built a new kernel once again

~ λ uname -a
NetBSD desktop.local 10.0_STABLE NetBSD 10.0_STABLE (MYKERNEL) #0: Mon Oct 28 17:54:45 AEDT 2024  dave@desktop.local:/usr/obj/sys/arch/amd64/compile/MYKERNEL amd64

Alacritty works now without issues, but I still need to set

export MOZ_ACCELERATED=0
export MOZ_WEBRENDER=0

for thunderbird and firefox to work.

I'm also still unable to play YouTube videos in firefox for some reason, it just buffers eternally ..

« Previous Page Next Page »