FS#5298 - Xorg 7.1: lockups with various VIA drivers

Attached to Project: Arch Linux
Opened by name withheld (Gullible Jones) - Sunday, 27 August 2006, 22:50 GMT
Last edited by Alexander Baldeck (kth5) - Friday, 18 May 2007, 00:46 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Alexander Baldeck (kth5)
Architecture All
Severity Critical
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

XOrg 7.1 seems subject to lockups when using drivers for VIA hardware. So far I've seen lockups with both xf86-video-via and openchrome:

- With xf86-video-via, XOrg invariably locks up immediately upon starting: blank screen, no response to any input, etc. Nothing oddball stands out in Xorg.0.log, no unusual errors or warnings.

- With openchrome, XOrg exhibited the same behavior when EXA was enabled. I'll see if it works with EXA enabled and AIGLX disabled.

- With xf86-video-unichrome, I haven't observed any lockups, though I may be able to induce some by messing around with xorg.conf. At any rate, I'm avoiding unichrome because using it results in an abnormally bright display with very washed-out color - very hard on the eyes, and I'm not willing to find out by experience if that can damage my monitor.

It must be noted that I never encounted this behavior, with any of the drivers, when using XOrg 7.1 compiled from the PKGBUILDs in this thread:

http://bbs.archlinux.org/viewtopic.php?t=22990

Which leads me to wonder if the patched version of Mesa used is in some way suspect.

I'll add comments to this bug report as new stuff surfaces...
This task depends upon

Closed by  Alexander Baldeck (kth5)
Friday, 18 May 2007, 00:46 GMT
Reason for closing:  Won't fix
Additional comments about closing:  we updated to xorg 7.2 long ago. via works for me currently.
Comment by name withheld (Gullible Jones) - Sunday, 27 August 2006, 22:57 GMT
Okay,the openchrome lockup occurs only when EXA is enabled. AIGLX being enabled has nothing to do with it.

(With the previous openchrome driver (same version) and XOrg 7.0, EXA did not cause any failures, which again leads me to believe that the driver isn't at fault.)
Comment by Jan de Groot (JGC) - Monday, 28 August 2006, 06:18 GMT
I found two git commits in the via driver that could be interesting, both are related to DRI problems:

Openchrome Changesets 189-192, 194.
Important memory management bugfix.
DRM compatibility check.


Bugzilla #6668 <https://bugs.freedesktop.org/show_bug.cgi?id=6668> Fix
critical unlibcwrap breakage. ("Morgoth")

I'll check those out later today, or, if you want to be helpful, you could apply the diffs yourself and see if it works out with xf86-video-via.
Comment by Jan de Groot (JGC) - Monday, 28 August 2006, 08:40 GMT
The fix mentioned in freedesktop bugzilla ID 6668 should fix the problem and describes exactly what you're experiencing. IMHO they should re-roll tarballs for such important fixes, even gnome does that with beta releases that crash.
Comment by name withheld (Gullible Jones) - Monday, 28 August 2006, 14:23 GMT
They claim it's fixed right now. They still haven't released an update?
Comment by Jan de Groot (JGC) - Monday, 28 August 2006, 14:39 GMT
No, that's what I mean with rolling updated tarballs. Sometimes important fixes can sit 3 months in CVS or git, just waiting for someone to release it.
Comment by name withheld (Gullible Jones) - Monday, 28 August 2006, 15:10 GMT
Grr... That is annoying. Would it be possible to backport the patch from CVS?
Comment by name withheld (Gullible Jones) - Monday, 28 August 2006, 16:41 GMT
Hmm, it looks like basilburn (the guy who made the 7.1 PKGBUILDs) put in some patches... Check out the xf86-video-via directory in this tarball:

http://www3.telus.net/public/virgp/xorg71.tbz2

The relevant one is missing-assert.patch:


diff -urpbB xf86-video-via/src/via.h xf86-video-via.assert/src/via.h
--- xf86-video-via/src/via.h 2006-04-21 10:42:21.000000000 +0200
+++ xf86-video-via.assert/src/via.h 2006-05-02 19:08:09.358006673 +0200
@@ -29,6 +29,7 @@
#include <string.h>
#include <stdio.h>
#include <math.h>
+#include <assert.h>

/* Video status flag */

That should fix it, I think.
Comment by Jan de Groot (JGC) - Monday, 28 August 2006, 18:03 GMT
fixed, try the -2 package, it contains another patch that could fix your OpenGL lockup problem also.
Comment by name withheld (Gullible Jones) - Monday, 28 August 2006, 18:04 GMT
Okay, I'll see how it works... Thanks.
Comment by name withheld (Gullible Jones) - Monday, 28 August 2006, 18:33 GMT
Yep, fixed. Thank you very much.
Comment by name withheld (Gullible Jones) - Monday, 28 August 2006, 19:33 GMT
Wait, my bad... The EXA crash is not fixed. Enabling EXA (Option "AccelMethod" "exa") seems to cause a lockup on start.

(When was the last time you wondered if the FD.O folks shouldn't rewrite the stupid server from scratch?)
Comment by name withheld (Gullible Jones) - Thursday, 31 August 2006, 23:08 GMT
Uh by the way... Should I submit a separate report for the EXA lock-on-start bug? Would it be considered outside the scope of this bug report or would it also fit in here?
Comment by Jan de Groot (JGC) - Friday, 01 September 2006, 06:06 GMT
I can't do much on the EXA bug other than submit it upstream. I could look into git for regular fixes, but that's all I can do about it. Filing another bug for a problem we can't fix ourself doesn't help much in this case. If it was a packaging bug then filing standalone bugs would be good yes.
Comment by name withheld (Gullible Jones) - Monday, 04 September 2006, 15:02 GMT
Hmm. FWIW, I never got EXA lockups with Basilburn's PKGBUILDs... It appears he used Mesa 6.5 and patched things to substitute for DESTDIR support - could this be a bug in Mesa 6.5.1 RC1?
Comment by Jan de Groot (JGC) - Saturday, 09 September 2006, 20:48 GMT
I added some patches to X.Org, one which contains a fix for lockups with AIGLX. Is this problem solved now?
Comment by name withheld (Gullible Jones) - Sunday, 10 September 2006, 03:53 GMT
Nope, both the EXA and indirect rendering lockups are still there.
Comment by name withheld (Gullible Jones) - Sunday, 24 September 2006, 23:15 GMT
Hmm. Maybe recompiling with the current version of Mesa (6.5.1) would fix this? Looks like a driver issue though. Odd.
Comment by name withheld (Gullible Jones) - Thursday, 23 November 2006, 17:01 GMT
Forcing indirect rendering with LIBGL_ALWAYS_INDIRECT has stopped working now. GL stuff will freeze X whether or not you use LIBGL_ALWAYS_INDIRECT. As usual, no log stuff, command line output, or anything to indicate the origin of the problem.

Loading...