Dear Maintainer,

After migrating from xserver-xorg-video-fglrx to xserver-xorg-video-radeon (when
fglrx dropped support for my card), X crashes when I log in to Minecraft,
specifically at the point where the program would transition from 2D to 3D
(OpenGL) mode. This is the only 3D application I really use on this machine, but
glxgears at least does work fine, as does standard 2D-application usage.

Even with every debugging-symbols package I know how to find installed, the
backtrace in Xorg.0.log contains only raw addresses rather than names. However,
I was able to obtain a backtrace according to the instructions on the
XStrikeForce/XServerDebugging page of wiki.debian.org; that is attached.

The console output of the Minecraft session involved is also attached, just in
case it might contain anything useful.

In case it might be relevant: when running under fglrx, I configured this copy
of Minecraft to use "advanced OpenGL", which seemed to provide a performance
improvement with no visible downside. This is stated to require OpenGL 2.0 or
later; I remember once seeing a statement of exactly what calls it uses, but I
can't find that now. It seems possible that disabling that setting might affect
the crash, but I don't see any way to access the configuration options without
getting past the crash first.

If there's anything I can do to help track this down, please don't hesitate to
let me know.

reassign 695594 libgl1-mesa-dri
kthxbye

It crashes in Mesa code, reassigning there.


Note that this crash means minecraft is using indirect rendering, which
is undesirable for a local display. Are you intentionally using indirect
rendering? If not, the output of

LIBGL_DEBUG=verbose glxinfo | grep render

might give hints as to why you're not getting direct rendering.

That was enough for me to track it down, albeit only with about four separate
searches of the entire root partition for one string or another.

It turns out to be because an earlier install of the FGLRX driver - I think from
before there was an officially distributed Debian package for it - had modified
/etc/profile to call /etc/ati/ati-fglrx.sh, which in turn would set
LIBGL_DRIVERS_PATH to something like
'/usr/lib/dri:/usr/lib32/dri:/usr/lib64/dri' if the path was not already set.

After commenting out that line from /etc/profile, and rebooting to be sure it
was cleared from the environment, the crash no longer occurs. I plan to also
clear out the other remnants of that old fglrx install when I have time.

Since Debian doesn't appear to set LIBGL_DRIVERS_PATH by default, but also
doesnt place the architecture-native DRI drivers (in this case, r600_dri.so) in
any of those three locations, they weren't being found. That led to fallback to
indirect rendering mode, which apparently led to the crash.

It's not good to crash when using indirect rendering, of course, and I'd be
willing to conduct tests to help track that crash down if desired - but at least
the direct-rendering mode does appear to work properly. (Though I'd like to know
why, judging from the output of glxgears, I seem to get enforced vsync with
radeon but didn't with fglrx... but that's not really related to this bug.)

The Wanderer <wanderer@fastmail.fm> (18/12/2012):

Because that's the default. vblank_mode=0 overrides that. Trivial to
find on: http://www.x.org/wiki/RadeonFeature#VSYNC

Mraw,
KiBi.