Intel HD Graphics (Braswell (Valleyview Cherryview)) no hardware acceleration after drm-510-kmod

grandpa · Jun 8, 2026

So, it breaks on 15. Probably because of the differences for linuxkpi. The first thing that comes up is a different slot macro that needs two arguments instead of one where _pbus is the new.

I also realized why it worked for me with the version 14 upgrades. It's because drm builds against /usr/src and I had the same source tree for all 14s and only had to rebuild once. I actually tried building 510 on 15 against the 14.1 source tree and it built just fine but on install I got the kernel mismatch notice.

For now it's possible to build drm-510 up to 14.4-RELEASE using the older source tree and get hardware acceleration, wayland plasma working. 14.4 STABLE has EOL near end of 2028 so that buys some time to fix 15.

To be clear. Install 14.4-RELEASE and then git clone the source code for 14.3. Git clone 2026Q2 ports tree and build drm-510-kmod. No patches needed. This will give working hardware acceleration for Braswell Cherryview (and most likely Valleyview as well) with 14.4-RELEASE.

 git clone -b releng/14.3 http://git.FreeBSD.org/src.git /usr/src

git clone -b 2026Q2 https://git.FreeBSD.org/ports.git /usr/ports

cd /usr/ports/graphics/drm-510-kmod

make install

 uname -a

FreeBSD asus-r517sa 14.4-RELEASE FreeBSD 14.4-RELEASE releng/14.4-n273675-a456f852d145 GENERIC amd64

pkg info | grep drm

drm-510-kmod-5.10.163.1404000_13 Direct Rendering Manager GPU drivers

glxinfo | grep render

'direct rendering: Yes

    GLX_MESA_copy_sub_buffer, GLX_MESA_gl_interop, GLX_MESA_query_renderer, 

    GLX_MESA_gl_interop, GLX_MESA_query_renderer, GLX_MESA_swap_control, 

Extended renderer info (GLX_MESA_query_renderer):

OpenGL renderer string: Mesa Intel(R) HD Graphics 405 (BSW)

/grandpa

grandpa · Jun 10, 2026

fahrenheit said:
Okay, so for clarity, assuming the loading the kernel driver doesn't panic, and the issues are only on X the issue may be related with mesa vs mesa-amber. I.e. drm-5.10 has the necessary code paths mesa uses but they may have changed stuff in drm 5.15+.

If that's the case, maybe this post helps: https://forums.freebsd.org/threads/how-to-migrate-to-amber-branch-for-mesa.89668/

Since the method described in #26 is a workaround we still need to find the root cause for how accel is breaking on drm-515 (and upwards).

Architecturally fahrenheit you are definitely correct. When I look at the below illustration of the Linux graphics drivers and consider that I am running the KDE install from chapter 8 in the FreeBSD Handbook the layers must be sddm/Xorg/mesa-dri. What keeps me getting back to drm-515 is the fact that the only change I do to break hw accel is replace drm-510 with drm-515.

Above is from commons.wikimedia.org

What bothers me is that when I boot with drm-515 I can see that the i915kms module is being loaded and that the console resolution switches. It’s when sddm pulls up Xorg that Xorg modesetting SIGABRTs. And not until somewhere where Modesetting either unloads modules or is enabling the backing store.

Something must have changed in the drm-515-kmod that breaks the modesetting. It might be that it’s not the driver code itself, ie drivers/gpu/drm/i915 but in the linuxkpi code?

There is something here that has to do with the reason for the Makefile restriction in drm-510 to only support <14.2.

/grandpa

grandpa · Jun 16, 2026

Another tidbit of information.

14.4-RELEASE with drm-515 and xorg-server built with -DWITH_DEBUG.

After boot and xorg SIGABRT logging in as user and just running Xorg from console gives the following output:

 LoaderOpen(/usr/local/lib/xorg/modules/drivers/vesa_drv.so)

scfb trace: probe start

scfb trace: probe done

LoaderOpen(/usr/local/lib/xorg/modules/libglamorgl.so)

(EE)

Fatal server error:

(EE) Caught signal 6 (Abort trap). Server aborting

(EE)

A quick gopher on the intrawebs says something about a commit for 08_dont-init-glamor-on-llvmpipe.diff that made xorg crash and where the user found a workaround by disabling hardware acceleration.

(And yes, I have used gopher many many years ago ..)

/grandpa

fahrenheit · Jun 16, 2026

grandpa it can be because of glamor (GL 2D acceleration) but if that is the case if you rebuild xorg without glamor it shouldn't crash. But you probably would need to use scfb (uefi) or vesa (bios) to get any desktop (I'm not sure if the older xf86-video-intel will work) and disable composition.

maybe?

grandpa · Jun 16, 2026

fahrenheit said:
grandpa it can be because of glamor (GL 2D acceleration) but if that is the case if you rebuild xorg without glamor it shouldn't crash. But you probably would need to use scfb (uefi) or vesa (bios) to get any desktop (I'm not sure if the older xf86-video-intel will work) and disable composition.

maybe?

Oh, I just noticed I have mistyped in #28. the DRM is 515. I have edited it.

I have drm-510 working on 14.4-RELEASE with hardware acceleration and plasma/wayland as in #26.

fahrenheit isn't glamor also 3D?

fahrenheit · Jun 17, 2026

grandpa said:
Oh, I just noticed I have mistyped in #28. the DRM is 515. I have edited it.

I have drm-510 working on 14.4-RELEASE with hardware acceleration and plasma/wayland as in #26.

fahrenheit isn't glamor also 3D?

As far as I know it's only 2D, I think 3D duties would fall to softpipe or similar.

grandpa · Jun 18, 2026

SirDice said:
Don't know for sure, but I suspect it has to do with changes in LinuxKPI. The DRM drivers lean heavily on it.

I must learn to pay more attention to your posts SirDice.

The code for drm-515-kmod is different from the one for drm-510-kmod and there are clear differences for linuxkpi in the jump from 14.3-RELEASE to 14.4-RELEASE.

Since I know nothing about how graphics drivers, xorg or anything works I can only guess. Browsing the source code it looks like there are changes for memory management in the linuxkpi and at this moment in time I suspect that integrated graphics cards like the Cherryview could be finicky about these changes since they don't have any memory of their own.

The complexity is that somewhere in the changes for linuxkpi going from 14.3 to 14.4 combined with a rewrite of drm-515 a bug crept in that has as symptom that xorg-server using modesetting sigabrts when loading libglamorgl.so. This bug follows the drm versions up to -latest so if it can be found and squashed Cherryview would most likely work on drm-latest.

It looks like drm-515 holds the bug but it could just as well be hiding in the linuxkpi code. The bug occurs at a precise "time" that is when 14.4 kernel source is combined with drm-515. I did a git checkout 041aa28386d for the kernel source (this is where 14.4 did update to RC1) but the changes are already in there from start.

I guess I need to look into linuxkpi.

/grandpa

grandpa · Jun 19, 2026

fahrenheit said:
Okay, so for clarity, assuming the loading the kernel driver doesn't panic, and the issues are only on X the issue may be related with mesa vs mesa-amber. I.e. drm-5.10 has the necessary code paths mesa uses but they may have changed stuff in drm 5.15+.

If that's the case, maybe this post helps: https://forums.freebsd.org/threads/how-to-migrate-to-amber-branch-for-mesa.89668/

I followed up on the amber track.

I build and installed mesa-amber as follows:

 git clone https://gitlab.freedesktop.org/mesa/mesa.git

cd mesa

git checkout amber

mkdir ../mesa-amber-build

pkg install python3

pkg install py311-mako py311-setuptools py311-packaging

pkg install bison

env YACC=bison meson setup --wipe ../mesa-amber-build/ \

  --prefix="/usr/local/mesa-amber" \

  -Damber=true \

  -Dplatforms=x11,wayland \

  -Ddri-drivers=i915,i965 \

  -Dbuildtype=release

meson compile -C ../mesa-amber-build/

sudo meson install -C ../mesa-amber-build/

After the install I have the following in /usr/local/lib/mesa-amber

 ls -al /usr/local/mesa-amber/lib

total 748

drwxr-xr-x  3 root wheel     15 Jun 19 23:22 .

drwxr-xr-x  6 root wheel      6 Jun 19 23:22 ..

drwxr-xr-x  2 root wheel      5 Jun 19 23:22 dri

lrwxr-xr-x  1 root wheel     17 Jun 19 23:22 libEGL_amber.so -> libEGL_amber.so.0

lrwxr-xr-x  1 root wheel     21 Jun 19 23:22 libEGL_amber.so.0 -> libEGL_amber.so.0.0.0

-rwxr-xr-x  1 root wheel 294072 Jun 19 23:22 libEGL_amber.so.0.0.0

lrwxr-xr-x  1 root wheel     17 Jun 19 23:22 libGLX_amber.so -> libGLX_amber.so.0

lrwxr-xr-x  1 root wheel     21 Jun 19 23:22 libGLX_amber.so.0 -> libGLX_amber.so.0.0.0

-rwxr-xr-x  1 root wheel 717744 Jun 19 23:22 libGLX_amber.so.0.0.0

lrwxr-xr-x  1 root wheel     11 Jun 19 23:22 libgbm.so -> libgbm.so.1

lrwxr-xr-x  1 root wheel     15 Jun 19 23:22 libgbm.so.1 -> libgbm.so.1.0.0

-rwxr-xr-x  1 root wheel  70808 Jun 19 23:22 libgbm.so.1.0.0

lrwxr-xr-x  1 root wheel     13 Jun 19 23:22 libglapi.so -> libglapi.so.0

lrwxr-xr-x  1 root wheel     17 Jun 19 23:22 libglapi.so.0 -> libglapi.so.0.0.0

-rwxr-xr-x  1 root wheel 485336 Jun 19 23:01 libglapi.so.0.0.0

I then add these line to /home/$USER/.shrc

 # Mesa-Amber environment paths

LD_LIBRARY_PATH="/usr/local/mesa-amber/lib"

__GLX_VENDOR_LIBRARY_NAME="amber"

LIBGL_DRIVERS_PATH="/usr/local/mesa-amber/lib/dri"



# Plasma Wayland configurations

QT_QPA_PLATFORM="wayland"

XDG_SESSION_TYPE="wayland"



# Export all the defined variables

export LD_LIBRARY_PATH __GLX_VENDOR_LIBRARY_NAME LIBGL_DRIVERS_PATH QT_QPA_PLATFORM XDG_SESSION_TYPE

With FreeBSD14.4 and drm-510-kmod (with drm-510 built against 14.3 kernel source as in #26 ) I reboot and I see this:

 glxinfo | grep -E "OpenGL version|renderer"

    GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_NV_float_buffer,

    GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method,

Extended renderer info (GLX_MESA_query_renderer):

OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 405 (BSW)

OpenGL version string: 3.0 Mesa 21.3.9 Amber (git-027ccc89b2)

So mesa-amber works just as well as the normal mesa for 14.4+drm-kmod (14.3 kernel source).

Unfortunately when I remove drm-510-kmod and install drm-515-kmod or drm-61-kmod I get the dreaded SIGABRT on boot.

Again it points to drm-515-kmod and the changes in linuxkpi.

/grandpa

T-Aoki · Jun 20, 2026

grandpa said:
I followed up on the amber track.

I build and installed mesa-amber as follows:

git clone https://gitlab.freedesktop.org/mesa/mesa.git cd mesa git checkout amber mkdir ../mesa-amber-build pkg install python3 pkg install py311-mako py311-setuptools py311-packaging pkg install bison env YACC=bison meson setup --wipe ../mesa-amber-build/ \ --prefix="/usr/local/mesa-amber" \ -Damber=true \ -Dplatforms=x11,wayland \ -Ddri-drivers=i915,i965 \ -Dbuildtype=release meson compile -C ../mesa-amber-build/ sudo meson install -C ../mesa-amber-build/

After the install I have the following in /usr/local/lib/mesa-amber

ls -al /usr/local/mesa-amber/lib total 748 drwxr-xr-x 3 root wheel 15 Jun 19 23:22 . drwxr-xr-x 6 root wheel 6 Jun 19 23:22 .. drwxr-xr-x 2 root wheel 5 Jun 19 23:22 dri lrwxr-xr-x 1 root wheel 17 Jun 19 23:22 libEGL_amber.so -> libEGL_amber.so.0 lrwxr-xr-x 1 root wheel 21 Jun 19 23:22 libEGL_amber.so.0 -> libEGL_amber.so.0.0.0 -rwxr-xr-x 1 root wheel 294072 Jun 19 23:22 libEGL_amber.so.0.0.0 lrwxr-xr-x 1 root wheel 17 Jun 19 23:22 libGLX_amber.so -> libGLX_amber.so.0 lrwxr-xr-x 1 root wheel 21 Jun 19 23:22 libGLX_amber.so.0 -> libGLX_amber.so.0.0.0 -rwxr-xr-x 1 root wheel 717744 Jun 19 23:22 libGLX_amber.so.0.0.0 lrwxr-xr-x 1 root wheel 11 Jun 19 23:22 libgbm.so -> libgbm.so.1 lrwxr-xr-x 1 root wheel 15 Jun 19 23:22 libgbm.so.1 -> libgbm.so.1.0.0 -rwxr-xr-x 1 root wheel 70808 Jun 19 23:22 libgbm.so.1.0.0 lrwxr-xr-x 1 root wheel 13 Jun 19 23:22 libglapi.so -> libglapi.so.0 lrwxr-xr-x 1 root wheel 17 Jun 19 23:22 libglapi.so.0 -> libglapi.so.0.0.0 -rwxr-xr-x 1 root wheel 485336 Jun 19 23:01 libglapi.so.0.0.0

I then add these line to /home/$USER/.shrc

# Mesa-Amber environment paths LD_LIBRARY_PATH="/usr/local/mesa-amber/lib" __GLX_VENDOR_LIBRARY_NAME="amber" LIBGL_DRIVERS_PATH="/usr/local/mesa-amber/lib/dri" # Plasma Wayland configurations QT_QPA_PLATFORM="wayland" XDG_SESSION_TYPE="wayland" # Export all the defined variables export LD_LIBRARY_PATH __GLX_VENDOR_LIBRARY_NAME LIBGL_DRIVERS_PATH QT_QPA_PLATFORM XDG_SESSION_TYPE

With FreeBSD14.4 and drm-510-kmod (with drm-510 built against 14.3 kernel source as in # ) I reboot and I see this:

glxinfo | grep -E "OpenGL version|renderer" GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_NV_float_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, Extended renderer info (GLX_MESA_query_renderer): OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 405 (BSW) OpenGL version string: 3.0 Mesa 21.3.9 Amber (git-027ccc89b2)

So mesa-amber works just as well as the normal mesa for 14.4+drm-kmod (14.3 kernel source).

Unfortunately when I remove drm-510-kmod and install drm-515-kmod or drm-61-kmod I get the dreaded SIGABRT on boot.

Again it points to drm-515-kmod and the changes in linuxkpi.

/grandpa

So you'll need

pkg lock graphics/drm-510-kmod

(and for anyone using hybrid graphics with NVIDIA dGPUs [aka Optimus] would need

pkg lock graphics/nvidia-drm-510-kmod,
pkg lock graphics/nvidia-drm-510-kmod-580 or
pkg lock graphics/nvidia-drm-510-kmod-devel

in conjunction with corresponding x11/{linux-}nvidia-{kmod|driver|libs}{-580|-devel} ports.
if any of these installed) before upcoming July.
On early July, new quarterly, 2026Q3, would be created. This means the aforementioned ports to be dissappeared.

But for hybrid graphics with NVIDIA dGPU users, it's strongly recommended to have local ports tree, readding

pkg lock graphics/nvidia-drm-510-kmod,
pkg lock graphics/nvidia-drm-510-kmod-580 or
pkg lock graphics/nvidia-drm-510-kmod-devel

you need to the tree and keep on maintaining by yourself.

When x11/nvidia-kmod{-580|-devel} for you is upgraded, you need to keep your local one above in sync.

In most cases, make makesum (on -580 or -devel, you'll need to edit NVIDIA_DISTVERSION?= line in Makefile to match the version string set, too) at graphics/nvidia-drm-510-kmod{-580|-devel}/ would be sufficient.

If something goes wrong, still living ones should get fixes. You'll need to backport the updates yourself (it's out of support by us).

grandpa · Jun 20, 2026

This is fun. I am learning alot.

I am trying to remotely debug the old asus laptop to see more in detail what is happening when xorg server logs the SIGABRT error. The old asus laptop is running FreeBSD 14.4-RELEASE with drm-515-kmod.

 cd /usr/ports/x11-servers/xorg-server && make -DWITH_DEBUG=yes && make reinstall

cd /usr/ports/graphics/mesa-dri && make WITH_DEBUG=yes && make reinstall

On the asus laptop I comment out sddm so it won't autostart

#sddm_enable="YES"

On the other laptop I connect to the asus via ssh and su to root.

Then I start remotely on the asus lldb like so:

 # lldb -- /usr/local/libexec/Xorg :1 -keeptty

(lldb) target create "/usr/local/libexec/Xorg"

Current executable set to '/usr/local/libexec/Xorg' (x86_64).

(lldb) settings set -- target.run-args  ":1" "-keeptty"

(lldb) target modules search-paths add / /

(lldb) process launch

Xorg starts on the asus and then SIGABRTS with the following:

 LoaderOpen(/usr/local/lib/xorg/modules/drivers/vesa_drv.so)

scfb trace: probe start

scfb trace: probe done

LoaderOpen(/usr/local/lib/xorg/modules/libglamoregl.so)

Process 1723 stopped

* thread #1, name = 'Xorg', stop reason = signal SIGABRT

    frame #0: 0x0000000826da14ca libc.so.7`__sys_thr_kill at thr_kill.S:4

At this point I can do (lldb) thread backtrace all from the other laptop and I get a rather long output that I'm putting into a spoiler tag here:

* thread #1, name = 'Xorg', stop reason = signal SIGABRT
* frame #0: 0x0000000826da14ca libc.so.7`__sys_thr_kill at thr_kill.S:4
frame #1: 0x0000000826d19f84 libc.so.7`__raise(s=6) at raise.c:50:10
frame #2: 0x0000000826dcdea9 libc.so.7`abort at abort.c:64:8
frame #3: 0x000000083cec5099 crocus_dri.so`___lldb_unnamed_symbol22123 + 1705
frame #4: 0x000000083cec2e90 crocus_dri.so`___lldb_unnamed_symbol22097 + 96
frame #5: 0x000000083cb98a7f crocus_dri.so`___lldb_unnamed_symbol17364 + 431
frame #6: 0x000000083c82334e crocus_dri.so`___lldb_unnamed_symbol10009 + 46
frame #7: 0x000000083c5c58de crocus_dri.so`___lldb_unnamed_symbol3461 + 222
frame #8: 0x000000083c84d641 crocus_dri.so`___lldb_unnamed_symbol10255 + 161
frame #9: 0x000000083c50bcfd crocus_dri.so`___lldb_unnamed_symbol1071 + 61
frame #10: 0x000000083c50e0fe crocus_dri.so`___lldb_unnamed_symbol1118 + 14
frame #11: 0x000000084aff84e8 libEGL_mesa.so.0`___lldb_unnamed_symbol789 + 312
frame #12: 0x000000084afea000 libEGL_mesa.so.0`___lldb_unnamed_symbol591 + 688
frame #13: 0x000000084ac533f1 libEGL.so.1`eglMakeCurrent + 785
frame #14: 0x0000000839c23c47 libglamoregl.so`glamor_egl_make_current(glamor_ctx=0x000030d7f1f302e8) at glamor_egl.c:86:5
frame #15: 0x0000000839c25590 libglamoregl.so`glamor_make_current(glamor_priv=0x000030d7f1f2c780) at glamor_utils.h:673:9
frame #16: 0x0000000839c259e4 libglamoregl.so`glamor_init(screen=0x000030d7f17f4400, flags=1) at glamor.c:676:5
frame #17: 0x00000008338de73f modesetting_drv.so`drmmode_init(pScrn=0x000030d7f16e5a00, drmmode=0x000030d7f16f8558) at drmmode_display.c:3726:14
frame #18: 0x00000008338d8716 modesetting_drv.so`ScreenInit(pScreen=0x000030d7f17f4400, argc=3, argv=0x0000000820a783f0) at driver.c:1881:9
frame #19: 0x000000000045ec94 Xorg`xf86ScreenInit(pScreen=0x000030d7f17f4400, argc=3, argv=0x0000000820a783f0) at xf86Init.c:267:12
frame #20: 0x00000000002ec2cf Xorg`AddScreen(pfnInit=(Xorg`xf86ScreenInit at xf86Init.c:263), argc=3, argv=0x0000000820a783f0) at dispatch.c:3999:10
frame #21: 0x000000000045e3d6 Xorg`InitOutput(pScreenInfo=0x000000000051a6e8, argc=3, argv=0x0000000820a783f0) at xf86Init.c:637:21
frame #22: 0x00000000002f1c99 Xorg`dix_main(argc=3, argv=0x0000000820a783f0, envp=0x0000000820a78410) at main.c:190:9
frame #23: 0x00000000004ddd0a Xorg`main(argc=3, argv=0x0000000820a783f0, envp=0x0000000820a78410) at stubmain.c:34:12
frame #24: 0x0000000826cee2f0 libc.so.7`__libc_start1(argc=3, argv=0x0000000820a783f0, env=0x0000000820a78410, cleanup=<unavailable>, mainX=(Xorg`main at stubmain.
c:33)) at libc_start1.c:180:7
frame #25: 0x000000000029d384 Xorg`_start at crt1_s.S:80
thread #2, name = 'Xorg'
frame #0: 0x0000000826da28ea libc.so.7`__sys_poll at _poll.S:4
frame #1: 0x00000008255069a1 libthr.so.3`__thr_poll(fds=0x0000000830863b30, nfds=2, timeout=-1) at thr_syscalls.c:335:8
frame #2: 0x0000000825f38110 libudev.so.0`___lldb_unnamed_symbol284 + 208
frame #3: 0x00000008254fae22 libthr.so.3`thread_start(curthread=0x000030d7f1242810) at thr_create.c:291:16
thread #3, name = 'Xorg:disk$0'
frame #0: 0x00000008254f80ac libthr.so.3`_umtx_op_err at _umtx_op_err.S:38
frame #1: 0x0000000825508092 libthr.so.3`_thr_umtx_timedwait_uint(mtx=<unavailable>, id=<unavailable>, clockid=<unavailable>, abstime=<unavailable>, shared=<unavai
lable>) at thr_umtx.c:233:10
frame #2: 0x00000008254fe739 libthr.so.3`_thr_sleep(curthread=<unavailable>, clockid=<unavailable>, abstime=<unavailable>) at thr_kern.c:197:9 [artificial]
frame #3: 0x00000008254f9cb1 libthr.so.3`cond_wait_common [inlined] cond_wait_user(cvp=0x000030d7f17cf480, mp=0x000030d7f1243d88, abstime=0x0000000000000000, cance
l=1) at thr_cond.c:317:11
frame #4: 0x00000008254f9bff libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=0x0000000000000000, cancel=1) at thr_cond.c:377:11
frame #5: 0x000000083c5ac289 crocus_dri.so`___lldb_unnamed_symbol3096 + 9
frame #6: 0x000000083c5833bf crocus_dri.so`___lldb_unnamed_symbol2749 + 559
frame #7: 0x000000083c5ac409 crocus_dri.so`___lldb_unnamed_symbol3102 + 25
frame #8: 0x00000008254fae22 libthr.so.3`thread_start(curthread=0x000030d7f1244010) at thr_create.c:291:16
thread #4, name = 'Xorg:gdrv0'
frame #0: 0x00000008254f80ac libthr.so.3`_umtx_op_err at _umtx_op_err.S:38
frame #1: 0x0000000825508092 libthr.so.3`_thr_umtx_timedwait_uint(mtx=<unavailable>, id=<unavailable>, clockid=<unavailable>, abstime=<unavailable>, shared=<unavai
lable>) at thr_umtx.c:233:10
frame #2: 0x00000008254fe739 libthr.so.3`_thr_sleep(curthread=<unavailable>, clockid=<unavailable>, abstime=<unavailable>) at thr_kern.c:197:9 [artificial]
frame #3: 0x00000008254f9cb1 libthr.so.3`cond_wait_common [inlined] cond_wait_user(cvp=0x000030d7f17cf820, mp=0x000030d7f1245308, abstime=0x0000000000000000, cance
l=1) at thr_cond.c:317:11
frame #4: 0x00000008254f9bff libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=0x0000000000000000, cancel=1) at thr_cond.c:377:11
frame #5: 0x000000083c5ac289 crocus_dri.so`___lldb_unnamed_symbol3096 + 9
frame #6: 0x000000083c5833bf crocus_dri.so`___lldb_unnamed_symbol2749 + 559
frame #7: 0x000000083c5ac409 crocus_dri.so`___lldb_unnamed_symbol3102 + 25
frame #8: 0x00000008254fae22 libthr.so.3`thread_start(curthread=0x000030d7f1244810) at thr_create.c:291:16
(lldb)

From what I can understand or guess the SIGABRT is caused by something in the crocus driver and for some reason I am not getting debug symbols to show in the backtrace.

frame #3: 0x000000083cec5099 crocus_dri.so`___lldb_unnamed_symbol22123 + 1705

The above probably means that somewhere 1705 bytes into a function in crocus_dri.so the SIGABRT is triggered.

I wonder what I need to do to turn those unnamed symbols into debug symbols?

/grandpa

grandpa · Jun 20, 2026

With a little push from the friendly people on Bugzilla I managed to get the debug symbols.

Output now looks like this and it looks like something is happening within crocus_batch.c.

LoaderOpen(/usr/local/lib/xorg/modules/libglamoregl.so)
Assertion failed: (batch->hw_ctx_id), function crocus_init_batch, file ../src/gallium/drivers/crocus/crocus_batch.c, line 210.
Process 6842 stopped
* thread #1, name = 'Xorg', stop reason = signal SIGABRT
frame #0: 0x0000000829e254ca libc.so.7`__sys_thr_kill at thr_kill.S:4
(lldb) thread backtrace all
* thread #1, name = 'Xorg', stop reason = signal SIGABRT
* frame #0: 0x0000000829e254ca libc.so.7`__sys_thr_kill at thr_kill.S:4
frame #1: 0x0000000829d9df84 libc.so.7`__raise(s=6) at raise.c:50:10
frame #2: 0x0000000829e51ea9 libc.so.7`abort at abort.c:64:8
frame #3: 0x0000000829d80e21 libc.so.7`__assert(func=<unavailable>, file=<unavailable>, line=<unavailable>, failedexpr=<unavailable>) at assert.c:49:2
frame #4: 0x000000083f1e52eb crocus_dri.so`crocus_init_batch(ice=0x00003d8522e2d1f0, name=CROCUS_BATCH_RENDER, priority=0) at crocus_batch.c:210:4
frame #5: 0x000000083f25ee49 crocus_dri.so`crocus_create_context(pscreen=0x00003d852265b030, priv=0x0000000000000000, flags=8) at crocus_context.c:323:7
frame #6: 0x000000083e5ae761 crocus_dri.so`st_api_create_context(fscreen=0x00003d8522706a80, attribs=0x0000000820eb5760, error=0x0000000820eb575c, shared_ctx=0x0000000000000000) at st_manager.c:986:11
frame #7: 0x000000083e054d20 crocus_dri.so`dri_create_context(screen=0x00003d8522706a80, api=API_OPENGL_CORE, visual=0x0000000000000000, ctx_config=0x0000000820eb58b4, error=0x0000000820eb591c, sharedContextPrivate=0x0000000000000000, loaderPrivate=0x00003d8522e21b60) at dri_context.c:178:14
frame #8: 0x000000083e058b1b crocus_dri.so`driCreateContextAttribs(psp=0x00003d8522706a80, api=3, config=0x0000000000000000, shared=0x0000000000000000, num_attribs=2, attribs=0x0000000820eb5920, error=0x0000000820eb591c, data=0x00003d8522e21b60) at dri_util.c:652:31
frame #9: 0x000000084baba30c libEGL_mesa.so.0`___lldb_unnamed_symbol787 + 684
frame #10: 0x000000084baabb1f libEGL_mesa.so.0`___lldb_unnamed_symbol589 + 367
frame #11: 0x000000083a6ea18d libglamoregl.so`glamor_egl_try_big_gl_api(scrn=0x00003d85226e5a00) at glamor_egl.c:988:31
frame #12: 0x000000083a6e9ea9 libglamoregl.so`glamor_egl_init(scrn=0x00003d85226e5a00, fd=14) at glamor_egl.c:1128:13
frame #13: 0x00000008359b9228 modesetting_drv.so`try_enable_glamor(pScrn=0x00003d85226e5a00) at driver.c:984:13
frame #14: 0x00000008359b7d33 modesetting_drv.so`PreInit(pScrn=0x00003d85226e5a00, flags=0) at driver.c:1211:5
frame #15: 0x000000000045db38 Xorg`InitOutput(pScreenInfo=0x000000000051a6e8, argc=3, argv=0x0000000820eb5d40) at xf86Init.c:478:17
frame #16: 0x00000000002f1c99 Xorg`dix_main(argc=3, argv=0x0000000820eb5d40, envp=0x0000000820eb5d60) at main.c:190:9
frame #17: 0x00000000004ddd0a Xorg`main(argc=3, argv=0x0000000820eb5d40, envp=0x0000000820eb5d60) at stubmain.c:34:12
frame #18: 0x0000000829d722f0 libc.so.7`__libc_start1(argc=3, argv=0x0000000820eb5d40, env=0x0000000820eb5d60, cleanup=<unavailable>, mainX=(Xorg`main at stubmain.c:33)) at libc_start1.c:180:7
frame #19: 0x000000000029d384 Xorg`_start at crt1_s.S:80
thread #2, name = 'Xorg'
frame #0: 0x0000000829e268ea libc.so.7`__sys_poll at _poll.S:4
frame #1: 0x0000000828a889a1 libthr.so.3`__thr_poll(fds=0x0000000831114b30, nfds=2, timeout=-1) at thr_syscalls.c:335:8
frame #2: 0x00000008286f4110 libudev.so.0`___lldb_unnamed_symbol284 + 208
frame #3: 0x0000000828a7ce22 libthr.so.3`thread_start(curthread=0x00003d8522242810) at thr_create.c:291:16
thread #3, name = 'Xorg:disk$0'
frame #0: 0x0000000828a7a0ac libthr.so.3`_umtx_op_err at _umtx_op_err.S:38
frame #1: 0x0000000828a8a092 libthr.so.3`_thr_umtx_timedwait_uint(mtx=<unavailable>, id=<unavailable>, clockid=<unavailable>, abstime=<unavailable>, shared=<unavailable>) at thr_umtx.c:233:10
frame #2: 0x0000000828a80739 libthr.so.3`_thr_sleep(curthread=<unavailable>, clockid=<unavailable>, abstime=<unavailable>) at thr_kern.c:197:9 [artificial]
frame #3: 0x0000000828a7bcb1 libthr.so.3`cond_wait_common [inlined] cond_wait_user(cvp=0x00003d85227cf520, mp=0x00003d8522243d88, abstime=0x0000000000000000, cancel=1) at thr_cond.c:317:11
frame #4: 0x0000000828a7bbff libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=0x0000000000000000, cancel=1) at thr_cond.c:377:11
frame #5: 0x000000083e0fc35d crocus_dri.so`cnd_wait(cond=0x00003d8522658860, mtx=0x00003d8522658850) at threads_posix.c:135:13
frame #6: 0x000000083e0d9fa5 crocus_dri.so`util_queue_thread_func(input=0x00003d852261e9a0) at u_queue.c:290:10
frame #7: 0x000000083e0fc680 crocus_dri.so`impl_thrd_routine(p=0x00003d852261e950) at threads_posix.c:67:29
frame #8: 0x0000000828a7ce22 libthr.so.3`thread_start(curthread=0x00003d8522244010) at thr_create.c:291:16

/grandpa

grandpa · Monday at 4:08 PM

So something is happening in crocus_batch.c in the vicinity of line 210.

C:

    186 void
    187 crocus_init_batch(struct crocus_context *ice,
    188                   enum crocus_batch_name name,
    189                   int priority)
    190 {
    191    struct crocus_batch *batch = &ice->batches[name];
    192    struct crocus_screen *screen = (struct crocus_screen *)ice->ctx.screen;
    193    struct intel_device_info *devinfo = &screen->devinfo;
    194
    195    batch->ice = ice;
    196    batch->screen = screen;
    197    batch->dbg = &ice->dbg;
    198    batch->reset = &ice->reset;
    199    batch->name = name;
    200    batch->contains_fence_signal = false;
    201
    202    if (devinfo->ver >= 7) {
    203       batch->fine_fences.uploader =
    204          u_upload_create(&ice->ctx, 4096, PIPE_BIND_CUSTOM,
    205                          PIPE_USAGE_STAGING, 0);
    206    }
    207    crocus_fine_fence_init(batch);
    208
    209    batch->hw_ctx_id = crocus_create_hw_context(screen->bufmgr);
    210    assert(batch->hw_ctx_id);
    211

Something must be wrong with batch->hw_ctx_id. Let's look at crocus_create_hw_context that's in crocus_bufmgr.c.

C:

   1521 uint32_t
   1522 crocus_create_hw_context(struct crocus_bufmgr *bufmgr)
   1523 {
   1524    uint32_t ctx_id;
   1525    if (!intel_gem_create_context(bufmgr->fd, &ctx_id)) {
   1526       DBG("intel_gem_create_context failed: %s\n", strerror(errno));
   1527       return 0;
   1528    }

This takes us to intel_gem_create_context which is in intel_gem.c.

C:

     64 bool
     65 intel_gem_create_context(int fd, uint32_t *context_id)
     66 {
     67    return i915_gem_create_context(fd, context_id);
     68 }

And that goes to i915/intel_gem.c

C:

     31 bool
     32 i915_gem_create_context(int fd, uint32_t *context_id)
     33 {
     34    struct drm_i915_gem_context_create create = {};
     35    if (intel_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, &create))
     36       return false;
     37    *context_id = create.ctx_id;
     38    return true;
     39 }

This goes on to intel_gem.h even though there is another intel_gem.h in the i915 subdirectory.

C:

     77 static inline int
     78 intel_ioctl(int fd, unsigned long request, void *arg)
     79 {
     80     int ret;
     81
     82     do {
     83         ret = ioctl(fd, request, arg);
     84     } while (ret == -1 && (errno == EINTR || errno == EAGAIN));
     85     return ret;
     86 }

And there it goes to libc.so.7 on line 83 and if cont it breaks.

 

Process 2307 stopped

* thread #1, name = 'Xorg', stop reason = instruction step into

    frame #0: 0x0000000840bb7a80 crocus_dri.so`intel_ioctl(fd=17, request=3221775469, arg=0x0000000820a03f40) at intel_gem.h:83:15

   80       int ret;

   81

   82       do {

-> 83           ret = ioctl(fd, request, arg);

   84       } while (ret == -1 && (errno == EINTR || errno == EAGAIN));

   85       return ret;

   86   }

(lldb) si

Process 2307 stopped

* thread #1, name = 'Xorg', stop reason = instruction step into

    frame #0: 0x0000000841352cd0 crocus_dri.so`ioctl

crocus_dri.so`ioctl:

->  0x841352cd0 <+0>:  jmpq   *0x6d352(%rip)

    0x841352cd6 <+6>:  pushq  $0x14

    0x841352cdb <+11>: jmp    0x841352b80



crocus_dri.so`dup:

    0x841352ce0 <+0>:  jmpq   *0x6d34a(%rip)

(lldb) si

Process 2307 stopped

* thread #1, name = 'Xorg', stop reason = instruction step into

    frame #0: 0x0000000828363a60 libc.so.7`__sys_ioctl at ioctl.S:4

(lldb)

Could the i915/intel_gem.h vs intel_gem.h be the issue?

/grandpa

grandpa · Tuesday at 8:28 PM

With help from the friendly people at Bugzilla it now looks like the SIGABRT is caused from the kernel aka linuxkpi. A question has been put to the kernel lords.

If anyone knows how to use lldb (or any other tool) to debug a kernel module please let me know. So far I can run lldb like so:

 lldb /boot/kernel/kernel --core /dev/mem

(lldb) image list

[  0] 575A19FD-E537-2BC5-DA81-37CFDF6420EC-F6735D48 0xffffffff80200000 /boot/kernel/kernel

      /usr/lib/debug/boot/kernel/kernel.debug

[  1] 8812A119-EEFE-E747-7E92-D595B1AC70D1-2F59E1AE 0xffffffff82146000 /boot/kernel/cryptodev.ko

      /usr/lib/debug/boot/kernel/cryptodev.ko.debug

[  2] EBBC2337-B397-8F53-5D16-CC60DA93E350-56EC260F 0xffffffff8214e000 /boot/kernel/zfs.ko

      /usr/lib/debug/boot/kernel/zfs.ko.debug

[  3] 3CAA14FB-EDCD-0AE9-5A50-F551CF77F00D-A6B9B077 0xffffffff82738000 /boot/kernel/snd_uaudio.ko

      /usr/lib/debug/boot/kernel/snd_uaudio.ko.debug

[  4] 0974F14B-5311-01E0-E5CB-1DBC67421EA5-B8E9CBC9 0xffffffff83200000 /boot/modules/i915kms.ko

I don't know where to go from here to set breakpoints and try to trace the ioctl from drm-515-kmod/drm-61-kmod in the i915kms kernel module?

Oh, and yes drm-61-kmod SIGABRTS at the same place.

/grandpa

grandpa · Wednesday at 6:34 AM

Reading up on https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/ tells me I could try DDB.

Let's build the kernel!

/grandpa

fahrenheit · Wednesday at 9:59 AM

My guess, and from what you already found out is that it's probably something related with fences (or lack of), it was also the cause of some issues for amdgpu.

grandpa · Wednesday at 7:12 PM

I compiled the kernel and added #option DDB and managed to hit ctrl alt escape when Xorg is starting up.

I set a breakpoint at sys_ioctl 0xfffffe008ade7d30 and then single stepped until the assertion came.

When I do ps the following looks interesting:

 100241 D - 0xfffff8000899d000 [i915]

100242 D - 0xfffff8000899ee00 [i915-dp]

100243 D - 0xfffff8000483ee00 [card0-crtc0]

100244 D - 0xfffff80000bc7200 [card0-crtc1]

100245 D - 0xfffff80000bc7c00 [card0-crtc2]

100246 D - 0xfffff80004657900 [i915_modeset]

show proc for the above processes says

 calltrap() at calltrap+0x8/frame 0xfffffe008ade7c10

---trap 0x3, rip = 0xfffff80be8480, rsp = 0xfffffe008ade7e08, rbp = 0xfffffe008ade7f30

sys_ioctl() at sys_ioctl/frame 0xfffffe008ade7f30

fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe008ade7f30

---syscall (54, FreeBSD ELF64, ioctl), rip=0x829382a6a, rsp=0x82074d8d8, rbp=0x82074d900

Wish I knew how to get more information here. It looks to be in the right place after dbus -> sddm -> xorg -> modesetting

/grandpa