Bug 217585

Summary: graphics/libGL: MESA-LOADER: failed to retrieve device information
Product: Ports & Packages Reporter: Ashley Chase <erisianash>
Component: Individual Port(s)Assignee: freebsd-x11 (Nobody) <x11>
Status: Closed FIXED    
Severity: Affects Only Me CC: info, jonathan, nbe
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
glxinfo output
none
"glxinfo" output from my Skylake notebook
none
"truss" log of the "glxinfo" execution...
none
workaround
none
Output of "glxinfo" with workarounded "libdrm-2.4.75_1,1" none

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.
(EE)
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 freebsd_triage 2017-03-06 15:59:57 UTC
Created attachment 180565 [details]
workaround

Can you show "ls -lL /dev/dri" output and try the attached workaround?
Comment 5 Nils Beyer 2017-03-06 16:16:49 UTC
Output:
================================================================================
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 freebsd_triage 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 freebsd_triage 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:
https://lists.freebsd.org/pipermail/freebsd-x11/2017-March/019076.html