nVidia Nouveau Driver

Johpin · January 21, 2025 at 11:54 AM New

Boot paramers
More precisely the parameter I am looking for is a cheatcode and is used like a boot parameter, for example "from=", see https://www.slax.org/blog/18824-Rei…tcode-from.html . I prefer dual boot in stead of booting from another hard disk of pen drive. This is more a topic for "feature requests", but it should streamline the process in my case (BIOS is sometimes not very responsive).

EGL
I don't know if is a bug. Slackware 15.0 is using version 21.3.5 without problems. They have patched mesa, but I don't think for EGL, see https://ftp.nluug.nl/os/Linux/distr…/source/x/mesa/ Kodi runs fine with gbm/gl

Images
40 minutes from scratch per image is very fast. Rebuilding without changes should take about 10 minutes for me. The results from your images:

Nouveau (gbm/gles):
pastekodi: https://paste.libreelec.tv/singular-civet.log
pastecrash: https://paste.libreelec.tv/aware-catfish.log
kodi_crashllog: https://paste.kodi.tv/eqehowusip.kodi

Nouveau-legacy (x11/gl):
pastekodi: https://paste.libreelec.tv/steady-doberman.log
systemctl status xorg.service and journalctl -xeu xorg.service: https://paste.kodi.tv/podibezacu

BTW I could not upgrade from Nouveau to Nouveau-legacy via .update It gave an error about not being compatible. I upgraded manually by coping the KERNEL and SYSTEM files.

EDIT I tried gbm/gl and therfore I changed the file /$HOME/LibreELEC.tv/projects/Generic/devices/gbm/options:
OPENGL="mesa", OPENGLES="no" and GRAPHIC_DRIVERS="nouveau"
During building I got the error ../meson.build:448:3: ERROR: Feature egl cannot be enabled: EGL requires DRI, Haiku, Windows or Android

**mglae** · January 21, 2025 at 4:18 PM New

No change to the errors, it is likely you get a working system by reverting Mesa 24 to 21.

IIRR Mesa 21 was the latest version booting on any platform (I'm testing) without error.

**chewitt** · January 22, 2025 at 6:39 AM New

On an RPi5 (and cross-checked on AMLGX, both are GBM) the Kodi debug log shows this sequence:

Code

eger_functions GL_EXT_color_buffer_half_float GL_EXT_texture_mirror_clamp_to_edge GL_KHR_parallel_shader_compile GL_EXT_EGL_image_storage GL_MESA_framebuffer_flip_y G
L_EXT_depth_clamp GL_EXT_texture_query_lod GL_MESA_sampler_objects GL_EXT_EGL_image_storage_compression GL_EXT_texture_storage_compression GL_MESA_bgra  
2025-01-22 10:13:39.738 T:10583   debug <general>: OnLostDevice - notify display change event
2025-01-22 10:13:39.738 T:10583   debug <general>: CDRMUtils::SetMode - found crtc mode: 1920x1080 @ 60 Hz
2025-01-22 10:13:39.738 T:10583    info <general>: GLES: Maximum texture width: 4096
2025-01-22 10:13:39.820 T:10583   debug <general>: EGL Debugging:
                                                   Error: EGL_BAD_SURFACE
                                                   Command: eglSwapBuffers
                                                   Type: EGL_DEBUG_MSG_ERROR_KHR
                                                   Message: dri2_swap_buffers
2025-01-22 10:13:39.823 T:10583   debug <general>: CDRMAtomic::FlipPage - Execute modeset at next commit
2025-01-22 10:13:39.831 T:10583   debug <general>: CWinSystemGbmGLESContext::PresentRender - Sending display reset to all clients

Display More

In the Nouveau (GBM) log the last item is GL_MESA_bgra so I am assuming the CDRMUtils::SetMode and whatever that translates into with the EGL context are the changes that trigger the segfault. I don't understand why we trip and show the EGL_BAD_SURFACE error, but this is normally harmless (shows on all GBM devices).

The crashlog shows:

Code

Thread 1 (Thread 0x7fd83dee5f40 (LWP 833)):
#0  0x00007fd840115a06 in ?? () from /usr/lib/libgallium-24.3.3.so
#1  0x00007fd8401575cc in ?? () from /usr/lib/libgallium-24.3.3.so
#2  0x00007fd8401578f4 in ?? () from /usr/lib/libgallium-24.3.3.so
#3  0x00007fd84015d92e in ?? () from /usr/lib/libgallium-24.3.3.so
#4  0x00007fd84007c18c in ?? () from /usr/lib/libgallium-24.3.3.so
#5  0x00007fd84007cdf9 in ?? () from /usr/lib/libgallium-24.3.3.so
#6  0x00007fd84015da31 in ?? () from /usr/lib/libgallium-24.3.3.so
#7  0x00007fd83fa8e3ec in ?? () from /usr/lib/libgallium-24.3.3.so
#8  0x00007fd83f9f65cb in dri_flush () from /usr/lib/libgallium-24.3.3.so
#9  0x00007fd842322e55 in ?? () from /usr/lib/libEGL.so.1
#10 0x00007fd84231ff13 in ?? () from /usr/lib/libEGL.so.1
#11 0x00007fd842314911 in eglSwapBuffers () from /usr/lib/libEGL.so.1
#12 0x00000000015094b0 in KODI::WINDOWING::GBM::CWinSystemGbmGLESContext::SetFullScreen(bool, RESOLUTION_INFO&, bool) ()
#13 0x0000000000c4caa8 in CGraphicContext::SetVideoResolutionInternal(RESOLUTION, bool) ()
#14 0x0000000000e934a0 in CApplication::InitWindow(RESOLUTION) ()
#15 0x0000000000e9aed6 in CApplication::CreateGUI() ()
#16 0x0000000000d469bd in XBMC_Run ()
#17 0x00000000008e6045 in main ()

Display More

I'm not an expert in backtraces, but it looks like we are opening a new context and we do something with buffers (which I assume trips EGL_BAD_SURFACE and then we see dri_flush and the segfault:

Code

Jan 21 08:23:48.613409 LibreELEC kernel: nouveau 0000:02:00.0: gr: intr 00100000 [ERROR] nsource 00000002 [DATA_ERROR] nstatus 02000000 [BAD_ARGUMENT] ch 2 [00061000 kodi.bin[833]] subc 7 class 4497 mthd 0208 data 00000120
Jan 21 08:23:48.616747 LibreELEC kernel: nouveau 0000:02:00.0: gr: intr 00100000 [ERROR] nsource 00000002 [DATA_ERROR] nstatus 02000000 [BAD_ARGUMENT] ch 2 [00061000 kodi.bin[833]] subc 7 class 4497 mthd 0208 data 00000120
Jan 21 08:23:48.620080 LibreELEC kernel: nouveau 0000:02:00.0: gr: intr 00100000 [ERROR] nsource 00000002 [DATA_ERROR] nstatus 02000000 [BAD_ARGUMENT] ch 2 [00061000 kodi.bin[833]] subc 7 class 4497 mthd 0208 data 00000120
Jan 21 08:23:48.623435 LibreELEC kernel: nouveau 0000:02:00.0: gr: intr 00100000 [ERROR] nsource 00000002 [DATA_ERROR] nstatus 02000000 [BAD_ARGUMENT] ch 2 [00061000 kodi.bin[833]] subc 7 class 4497 mthd 0208 data 00000140
Jan 21 08:23:48.810100 LibreELEC kernel: kodi.bin[833]: segfault at 0 ip 00007fd840115a06 sp 00007fff2122b1c0 error 6 in libgallium-24.3.3.so[786a06,7fd83f98f000+111f000] likely on CPU 1 (core 1, socket 0)
Jan 21 08:23:48.810300 LibreELEC kernel: Code: 00 00 48 8b bf f8 04 00 00 48 89 04 24 8b 82 d8 02 00 00 c7 44 24 08 02 03 00 00 83 c0 01 89 82 d8 02 00 00 89 06 48 8b 47 30 <48> c7 00 6c fd 08 00 8b 16 48 8d 48 0c 48 89 e6 48 89 4f 30 89 50

I'm no expert in mesa debugging, but can you set the following to see if we can get more output:

Code

echo "NOUVEAU_LIBDRM_DEBUG=1" > /storage/.config/kodi.conf
echo "NOUVEAU_DEBUG=1" >> /storage/.config/kodi.conf
echo "EGL_LOG_LEVEL=debug" >> /storage/.config/kodi.conf
reboot

Then pastebin the Kodi crashlog URL as before.

Johpin · January 22, 2025 at 8:28 AM New

After downloading the latest Nouveau tar file (22nd of January) and adding kodi.conf the following crash file appeared: https://paste.kodi.tv/uyazawigol.kodi

**chewitt** · January 22, 2025 at 8:34 AM New

Johpin can you share the system log too? .. Kodi dumps the environment debug there not to it's own log.

Johpin · January 22, 2025 at 9:24 AM New

Quote from chewitt

Johpin can you share the system log too? .. Kodi dumps the environment debug there not to it's own log.

What is the name of the file and what is the path?

I found a new version of Nouveau-Legacy and had installed it already. Before reverting to the Nouveau version, which information do you need from Nouveau-Legacy?

Downgrading to mesa-21.3.5. (taken from Slackware, because 21.0.3. from LE 10.04 was not in the archive anymore) gave the same EGL error during building. The patches Slackware is using have not been applied.

**chewitt** · January 22, 2025 at 9:40 AM New

Run "journalctl | paste" and share the URL

Johpin · January 22, 2025 at 10:05 AM New

journalctl for Nouveau version: https://paste.kodi.tv/mowehanivo

**chewitt** · January 22, 2025 at 11:58 AM New

Looks like something went wrong in the paste upload, as it's only 200 lines long.

Johpin · January 22, 2025 at 3:03 PM New

New attempt journalctl for Nouveau version: https://paste.kodi.tv/utikokoyic

**chewitt** · January 22, 2025 at 3:25 PM New

It's not particularly enlightening for me, but it might be more meaningful to a mesa developer

I'm currently building a GBM image based on the LE12 codebase. K22 contains some reworking to GLES shaders. So I'd like to run a test with K21 as it predates those changes and we can eliminate them from suspicion.

**chewitt** · January 23, 2025 at 1:30 AM New

I uploaded some LE 12.0.2 images to https://chewitt.libreelec.tv/testing/ .. please run the "Nouveau" image with Kodi in debug mode (via advancedsettings.xml) and with the kodi.conf changes, and and see if it works or not. If not (which is the expectation) and share the crash log and system log (if not included in the crash log). Thanks.

Johpin · January 23, 2025 at 8:15 AM New

LibreELEC-Nouveau.x86_64-12.80.1.tar

264 MiB

1/22/2025, 12:57:27 PM

Stops at kodi.target, pastecrash: https://paste.libreelec.tv/proper-rat.log

gbm/gl:
Replaced mesa by mesa 21.3.5 (from Slackware) => features egl can not be enabled: EGL reuires DRI,Haiku, Windows or Android
Added -Ddri-drivers="nouveau" to configuration of mesa in package.mk => ERROR: Dependency "gl" not found

**chewitt** · January 23, 2025 at 9:37 AM New

I don't see any difference in the log, which is positive as we can eliminate Kodi changes from suspicion and focus on interaction between libgallium and the kernel driver. I think it's time to push discussion to the mesa mailing list.

NB: Rolling back the mesa version back that far will require more than a simple version/sha256 change in package.mk as the build options have changed format and things have been added/removed over time (look at the git history for mesa package.mk). I did look at reverting, but in the end we need to fix the current version so better to pursue that for now.

**chewitt** · January 23, 2025 at 1:45 PM New

mglae See the IRC chat that starts here: https://oftc.irclog.whitequark.org/dri-devel/2025-01-23#33941062

This change causes the dri2 error under X11: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29969 - so I've added support for legacy-x11=dri2 in mesa package.mk

Johpin I've pushed an updated pair of images to https://chewitt.libreelec.tv/testing/ and I have a hunch "Nouveau-Legacy" with DRI2 support should now work? - If it does, please test whether this /storage/.config/xorg.conf also works? (probably not)

Code

Section "Device"
    Identifier "Nouveau"
    Driver "nouveau"
    Option "DRI" "3"
EndSection

The main mission is still to get GBM working so nouveau can be added to the normal Generic image. I'll need to chat with Kodi devs about that though, I'm not really understanding the DRM format comments in the IRC chat.

Johpin · January 23, 2025 at 3:37 PM New

LibreELEC-Nouveau-Legacy.x86_64-12.80.1.tar

267 MiB

1/23/2025, 4:05:21 PM

Shows pointer on a black screen, like earlier.
pastekodi: https://paste.libreelec.tv/pleasant-yak.log
journalctl: https://paste.kodi.tv/bipafelavi
Xorg.0.log: https://paste.kodi.tv/otixikawed
pastecrash: https://paste.libreelec.tv/mighty-stallion.log

LibreELEC-Nouveau.x86_64-12.80.1.tar

264 MiB

1/23/2025, 4:05:19 PM

pastekodi: https://paste.libreelec.tv/literate-mole.log
journalctl: https://paste.kodi.tv/koqakahoya
pastecrash: https://paste.libreelec.tv/evident-walrus.log

**chewitt** · January 23, 2025 at 4:26 PM New

Xorg now looks generally happy (some xorg.conf tweaking can clean some minor things up) but it now clearly shows an identical fault to the GBM image, so the IRC comments about "using linear scanout with depth" apply and we need to tweak something on the Kodi side to resolve this.

**chewitt** · January 23, 2025 at 4:42 PM New

Johpin can you run "modetest | paste" on the 'Nouveau' (GBM) image and share the URL please.