Bug 98629 - OpenGL applications warns "MESA-LOADER: failed to retrieve device information"
Summary: OpenGL applications warns "MESA-LOADER: failed to retrieve device information"
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: libdrm (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-07 19:36 UTC by Mingcong Bai
Modified: 2017-04-24 10:15 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
strace of glxinfo (77.26 KB, text/plain)
2016-11-08 23:54 UTC, Mingcong Bai
no flags Details
output of `cat /sys/dev/char/226:0/device/uevent` (263 bytes, text/plain)
2016-11-09 18:50 UTC, Mingcong Bai
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mingcong Bai 2016-11-07 19:36:07 UTC
After updating to Mesa 13.0.0 on my PowerMac G5 with NVIDIA GeForce 6600LE, OpenGL applications outputs errors like:

MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information

... upon launch. The program worked without issue despite the warning.

However, I did not get such warning from Mesa 12.0.3, is this something worth looking into?
Comment 1 Emil Velikov 2016-11-08 15:44:23 UTC
[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
Comment 2 Mingcong Bai 2016-11-08 23:54:35 UTC
Created attachment 127852 [details]
strace of glxinfo
Comment 3 Mingcong Bai 2016-11-08 23:55:15 UTC
(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.
Comment 4 Emil Velikov 2016-11-09 18:29:28 UTC
Thanks. What's the output of
$cat /sys/dev/char/226:0/device/uevent
Comment 5 Mingcong Bai 2016-11-09 18:50:11 UTC
Created attachment 127869 [details]
output of `cat /sys/dev/char/226:0/device/uevent`

Here you are.
Comment 6 Emil Velikov 2016-11-15 11:23:07 UTC
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
Comment 7 Brian Paul 2017-03-27 15:03:43 UTC
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.
Comment 8 Emil Velikov 2017-03-28 12:05:01 UTC
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/
Comment 9 Emil Velikov 2017-04-12 19:08:18 UTC
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.
Comment 10 Joachim Frieben 2017-04-22 09:35:56 UTC
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
Comment 11 Emil Velikov 2017-04-24 10:15:53 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.