Bug 217585 - graphics/libGL: MESA-LOADER: failed to retrieve device information
Summary: graphics/libGL: MESA-LOADER: failed to retrieve device information
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
Depends on:
Reported: 2017-03-06 13:45 UTC by Ashley Chase
Modified: 2017-03-14 15:07 UTC (History)
3 users (show)

See Also:

glxinfo output (9.44 KB, text/plain)
2017-03-06 13:45 UTC, Ashley Chase
no flags Details
"glxinfo" output from my Skylake notebook (9.68 KB, text/plain)
2017-03-06 14:50 UTC, Nils Beyer
no flags Details
"truss" log of the "glxinfo" execution... (58.53 KB, text/plain)
2017-03-06 15:26 UTC, Nils Beyer
no flags Details
workaround (2.92 KB, patch)
2017-03-06 15:59 UTC, Jan Beich
no flags Details | Diff
Output of "glxinfo" with workarounded "libdrm-2.4.75_1,1" (27.18 KB, text/x-log)
2017-03-06 16:18 UTC, Nils Beyer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ashley Chase 2017-03-06 13:45:57 UTC
Created attachment 180560 [details]
glxinfo output

I'm running the drm-next branch on a Lenovo Thinkpad T450s with Intel HD 5500 graphics.

When testing the CFT for the Xorg 1.18 update gl worked as expected and modesetting+glamor worked flawlessly, however the Xorg+Mesa update has resulted in the following:

* X fails to start with the modesetting driver reporting 

MESA-LOADER: failed to retrieve device information
Require OpenGL version 2.1 or later.
Fatal server error:
(EE) AddScreen/ScreenInit failed for driver 0

on the console.

* X starts with the intel driver but glxgears causes the screen to stop updating (except for the mouse pointer. glxinfo prints the same MESA-LOADER error and also reports "OpenGL renderer string: Mesa DRI Unknown Intel Chipset".

I've observed this behavior on drm-next and TrueOS.
Comment 1 Nils Beyer 2017-03-06 14:50:18 UTC
Created attachment 180561 [details]
"glxinfo" output from my Skylake notebook
Comment 2 Nils Beyer 2017-03-06 15:26:10 UTC
Same here on "FreeBSD 12.0-CURRENT #0 83893485a9c(drm-next)-dirty: Mon Mar  6 15:15:39 CET 2017".

Reverting to "libdrm-2.4.74_1,1" and keeping "dri" up-to-date don't help.
Reverting to "dri-13.0.4,2" and keeping "libdrm" up-to-date doe't help.
Reverting to "dri-13.0.4,2" and to "libdrm-2.4.74_1,1" don't help.

Reverting my kernel to "drm-next-4.7"-branch and keeping "libdrm" + "dri" up-to-date is working (apart from graphical artifacts), so I think, that something is changed/broken in "drm-next".

I've attached a "truss"-Log from the "glxinfo" execution...
Comment 3 Nils Beyer 2017-03-06 15:26:38 UTC
Created attachment 180563 [details]
"truss" log of the "glxinfo" execution...
Comment 4 Jan Beich freebsd_committer 2017-03-06 15:59:57 UTC
Created attachment 180565 [details]

Can you show "ls -lL /dev/dri" output and try the attached workaround?
Comment 5 Nils Beyer 2017-03-06 16:16:49 UTC
root@discofox:/root/#ls -lL /dev/dri
total 0
crw-rw----  1 root  video  0x16f Mar  6 15:19 card0
crw-rw----  1 root  video  0x1af Mar  6 15:19 controlD64
crw-rw----  1 root  video  0x1ef Mar  6 15:19 renderD128

I've applied your workaround, and it works (s. attachment) - thank you very much...
Comment 6 Nils Beyer 2017-03-06 16:18:47 UTC
Created attachment 180566 [details]
Output of "glxinfo" with workarounded "libdrm-2.4.75_1,1"
Comment 7 Jonathan Anderson freebsd_committer 2017-03-08 20:01:15 UTC
That workaround helps me, too. Thanks!
Comment 8 Juan Ramón Molina Menor 2017-03-09 21:45:07 UTC
Confirmed here too with drm-next.
Comment 9 Jan Beich freebsd_committer 2017-03-14 15:07:42 UTC
Worked around by rezny in ports r436156. The proper fix is likely to follow up on the following: