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)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-06 13:45 UTC by Ashley Chase
Modified: 2017-03-14 15:07 UTC (History)
3 users (show)

See Also:

Attachments
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
View All Add an attachment (proposed patch, testcase, etc.)

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.
(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