Bug 98629

[Moving to 'core' since it's not really nouveau specific]

Does this happen with glxinfo/glxgears as well ? If so can you attach the output of $strace glxinfo

If glxinfo works fine, while $program does not, attach the output of $DL_DEBUG=libs $program

Thanks

Created attachment 127852 [details]
strace of glxinfo

(In reply to Emil Velikov from comment #1)
> [Moving to 'core' since it's not really nouveau specific]
> 
> Does this happen with glxinfo/glxgears as well ? If so can you attach the
> output of $strace glxinfo
> 
> If glxinfo works fine, while $program does not, attach the output of
> $DL_DEBUG=libs $program
> 
> Thanks

glxinfo and glxgears... and basically everything provided by mesa-demos have the same issue.

Thanks. What's the output of
$cat /sys/dev/char/226:0/device/uevent

Created attachment 127869 [details]
output of `cat /sys/dev/char/226:0/device/uevent`

Here you are.

Fixed with the following commit, which is part of libdrm 2.4.73.
Thanks for the report and testing !

commit f53d3542c1dfa2a1c1a5a7155d058df9a6bcce7b
Author: Emil Velikov <emil.velikov@collabora.com>
Date:   Fri Nov 11 19:04:11 2016 +0000

    xd86drm: read more than 128 bytes of uevent in drmParsePciBusInfo

Hi Emil,

I'm still seeing this issue "MESA-LOADER: failed to retrieve device information" on Fedora 25 when I test our VMware driver.

It's failing for me in drmGetDevice2() at line 3791:

     if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
         return -EINVAL;

The value of maj is 245 but the expected DRM_MAJOR is 226.

$ ls -l /dev/dri*
crw-rw----+ 1 root video 245,   0 Mar 23 09:39 /dev/dri/card0
crw-------. 1 root video 245,  64 Mar 23 09:32 /dev/dri/controlD64
crw-rw----+ 1 root video 245, 128 Mar 23 09:32 /dev/dri/renderD128

I don't know where the 245 major device number is coming from.
If I disable the maj != DRM_MAJOR tests, I don't see the error msg and things run fine.

On Ubuntu, the dri device files have major number is the expected 226
which corresponds to the value of DRM_MAJOR as defined in vmwgfx's
drmP.h file so I don't see the error msg.

Hi Brian,

The define is coming from the kernel's drmP.h. Perhaps we should have explicitly made it part of the public API/ABI, but that won't help here.

In upstream the major is set in drm_core_init()'s register_chrdev(DRM_MAJOR...).

After a couple of "???" moments I clicked that you're likely having a problem with the standalone repo [1].

In there VMWGFX_STANDALONE is set, thus the upstream code path is not hit. You guys are using drm_chr_dev [see vmwgfx_chrdev_reg()], and where AFAICT MAJOR is not initialised.

Would be great if you can fix things on your end, but I won't object against a workaround in libdrm.

[1] https://cgit.freedesktop.org/mesa/vmwgfx/

Seems like I forgot to mention - drm_chr_dev() itself picks the first unused major.
So it's not like it's uninitialised, but rather random and non-deterministic.

For current Fedora 25 plus testing updates, I do still get this error message when using VirGL in a virtual machine:

$ glxgears 
libGL error: MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.

Installed packages include:
kernel-4.10.11-200.fc25
libdrm-2.4.79-1.fc25
mesa-13.0.4-3.fc25

Furthermore, permissions for /dev/libdri* read:

$ ls -l /dev/dri*
total 0
crw-rw----+ 1 root video 226,   0 Apr 22 11:27 card0
crw-rw----+ 1 root video 226, 128 Apr 22 11:24 renderD128

Joachim doing the "me too" trick, does not help much ;-(

Please add a few debugging printfs within drmGetDevices2 function and attach that within a separate bug report.

Brian, please try and fix this in mesa/vmwgfx. Alternatively do send a clearly documented patch that relaxes the DRM_MAJOR restriction.

I'm closing this as the original issue was fixed with f53d3542c1dfa2a1c1a5a7155d058df9a6bcce7b which is part for libdrm 2.4.73.