Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#5307 - Xorg shouldn't lock up when indirect rendering is forced
Attached to Project:
Arch Linux
Opened by name withheld (Gullible Jones) - Monday, 28 August 2006, 17:41 GMT
Last edited by Alexander Baldeck (kth5) - Friday, 09 November 2007, 14:27 GMT
Opened by name withheld (Gullible Jones) - Monday, 28 August 2006, 17:41 GMT
Last edited by Alexander Baldeck (kth5) - Friday, 09 November 2007, 14:27 GMT
|
DetailsIf Xorg is forced to use indirect rendering for OpenGL stuff (by removing DRI section in xorg.conf and enabling LIBGL_ALWAYS_INDIRECT in /etc/profile), and AGPDMA is disabled, it will always lock up when an OpenGL application is started. If AGPDMA is enabled in xorg.conf (Option "EnableAGPDMA"), no lockups will occur; however, CPU usage will rise to almost 100%. As is typical for X hijinks like this, there's nothing suspect in the logs.
So far I've only observed this with the openchrome driver using the repo version of Xorg 7.1. However, I have observed something similar when using basilburn's PKGBUILDs - if user access to DRI is denied, but indirect rendering is not forced via LIBGL_ALWAYS_INDIRECT, then Xorg will lock up instead of using indirect rendering when you try to run an OpenGL application. Anyway, I'll see if I can reproduce this with xf86-video-unichrome as well... |
This task depends upon
Closed by Alexander Baldeck (kth5)
Friday, 09 November 2007, 14:27 GMT
Reason for closing: Deferred
Additional comments about closing: Apparently fixed, reopen if need be.
Friday, 09 November 2007, 14:27 GMT
Reason for closing: Deferred
Additional comments about closing: Apparently fixed, reopen if need be.
XOrg still locks on OpenGL stuff when you deny permission to /dev/dri without using LIBGL_ALWAYS_INDIRECT, although right now it at least claims to be reverting to indirect rendering. Something's still screwing up, but not as badly as before.
Regarding AGPDMA, it no longer has to be enabled to prevent freezes. However, glxgears causes 100% CPU usage (without freeze) using either direct or indirect rendering, with or without AGPDMA, so I think the problem with CPU usage lies in mesa-apps needing recompilation.
(I'm not sure how much other stuff, if any, is built against mesa, but I'm guessing some of it might need to be recompiled.)
When utilizing software rendering with AIGLX turned off, things work just fine as it did with X.Org 7.0.
If your videocard can't do AIGLX properly, I guess it's best to just turn it off, you can disable AIGLX from xorg.conf.
I'll see if I can reproduce the 100% CPU thing using DRI with AIGLX off, and with PPRacer.
I think there are 3 things going on here...
1. I have a crappy low-powered CPU.
2. I have crappy low-powered graphics hardware.
3. GLXGears is designed to be piggish, even if it's not a good benchmark.
The extra CPU usage when forcing AIGLX could probably be chalked up to less-than-optimal support by the drivers, or maybe just the way AIGLX works, not sure about that.
The problem with forcing indirect rendering is still irking me though. If the user can't use /dev/dri, Xorg should use AIGLX even if you haven't put 'export LIBGL_ALWAYS_INDIRECT=1' in /etc/profile, or at least fall back on software rendering, instead of locking.
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 2036 requests (1072 known processed) with 0 events remaining.
Not sure what the significance of that is. I'll see if any other GL application generates it.