FS#34040 - X does not start on vmware workstation (have something to do with mesa and llvm?)

Attached to Project: Arch Linux
Opened by Michael Koloberdin (mkoloberdin) - Tuesday, 26 February 2013, 23:33 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 23 March 2013, 16:32 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture x86_64
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 20
Private No

Details

Description:

After updating mesa to the latest version X does not start anymore.

Additional info:

* package versions
xorg-server 1.13.2.901-1
mesa 9.1-2

* config and/or log files etc.

** Hardware: VMWare Workstation 9.0
** The log file is attached, here are also a couple of lines from its tail:

Loading extension GLX
X: /build/src/llvm-a58e8892a2225a5095cc9fc76f9f00d0b6ff50a8/include/llvm/Support/CommandLine.h:646: void llvm::cl::parser<DataType>::addLiteralOption(const char*, const DT&, const char*) [with DT = llvm::ScheduleDAGSDNodes* (*)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level); DataType = llvm::ScheduleDAGSDNodes* (*)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)]: Assertion `findOption(Name) == Values.size() && "Option already exists!"' failed.

Steps to reproduce:
Run graphical desktop on VMWare
   kdm.log (2.9 KiB)
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Saturday, 23 March 2013, 16:32 GMT
Reason for closing:  Upstream
Additional comments about closing:  we are CC'ed to the upstream bug
Comment by Michael Koloberdin (mkoloberdin) - Tuesday, 26 February 2013, 23:34 GMT
Forgot to mention that the same setup works fine on real HW with Intel GPU.
Comment by Marcin Rzeźnicki (mrzeznicki) - Wednesday, 27 February 2013, 00:18 GMT
I can confirm this. It has already been reported upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=61364

PS. Downgrading mesa to 9.0.2 (painful as hell because of packaging changes) solves the problem

Comment by Michael Koloberdin (mkoloberdin) - Wednesday, 27 February 2013, 00:27 GMT
Downgrading mesa to 9.0.2 worked for me too.
Comment by enricomaria pavan (pvnn) - Wednesday, 06 March 2013, 09:30 GMT
Same problem here.
Vmware Player 3.1.4
Arch 32bit
Comment by Marcin Rzeźnicki (mrzeznicki) - Wednesday, 06 March 2013, 22:52 GMT
Someone from llvm commented that: "This is an assertion that a static initializer is not called twice. Are you loading two copies of llvm that may share symbols?"
( http://llvm.org/bugs/show_bug.cgi?id=15410#c1 ) - is this something that arch crew can check?
Comment by Marcin Rzeźnicki (mrzeznicki) - Wednesday, 06 March 2013, 22:58 GMT
Oh, and one more thing - there is this, potentially interesting, commit to the svga module:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=44a5b5d161db496ec6a9c450a0f369b3356696f2
Comment by Alex Smith (xyzzy) - Thursday, 07 March 2013, 20:41 GMT
As pointed out in this thread, rebuilding with glx-tls disabled works around the issue: https://bbs.archlinux.org/viewtopic.php?pid=1238371
Comment by enricomaria pavan (pvnn) - Friday, 08 March 2013, 07:59 GMT
xyzzy tip worked for me.
Comment by Marcin Rzeźnicki (mrzeznicki) - Saturday, 09 March 2013, 21:16 GMT
Great to hear that this workaround is working. Andreas, could you release the version with glx-tls disabled for now, please?
Comment by Andreas Radke (AndyRTR) - Sunday, 10 March 2013, 09:14 GMT
No. I can't drop a feature that other drivers depend on only because your driver is buggy. Use abs meanwhile and kick upstreams ass to ship a proper driver fix.

note: at least new glamor acceleration requires glx-tls in mesa and we have request for this.
Comment by Marcin Rzeźnicki (mrzeznicki) - Monday, 11 March 2013, 10:05 GMT
Yes, you're right. Moreover, rebuilding mesa without --enable-glx-tls did not change anything on my machine so this may not be valid workaround in all cases.
Comment by Philipp Claßen (PhCl) - Thursday, 21 March 2013, 21:20 GMT
Mesa 9.1.1 didn't fix the problem on my system.

Update:
When I create an Xorg.conf file with the following entry

Section "Module"
Disable "glx"
EndSection

it fails with a stacktrace, which is exactly the same as in https://bugs.archlinux.org/task/32612 ("Pixman update isn't that great"). I attached the Xorg.0.log files before and after creating the Xorg.conf file.

After downgrading several xorg-server and xorg-server-common (including dependences), it works with Mesa 9.1.1:
pacman -U xorg-server-1.13.2.901-1-x86_64.pkg.tar.xz xorg-server-common-1.13.2.901-1-x86_64.pkg.tar.xz xf86-input-evdev-2.7.3-2-x86_64.pkg.tar.xz xf86-input-vmmouse-13.0.0-1-x86_64.pkg.tar.xz xf86-video-vesa-2.3.2-2-x86_64.pkg.tar.xz xf86-video-vmware-13.0.0-1-x86_64.pkg.tar.xz
   Xorg.0.log-before-disabling-g... (13.1 KiB)
   Xorg.0.log-after-disabling-glx (28.7 KiB)
Comment by Marcin Rzeźnicki (mrzeznicki) - Friday, 22 March 2013, 15:09 GMT
Mesa 9.1.1 wasn't supposed to fix this, judging from what went into this release. See mesa bug report, it is pretty much under everyone's radar.
Upgrading xorg to 1.14 triggers another problem in vmware's driver. It is not yet right time to upgrade it, probably we'll have to wait till vmware does something about new pixman cache.

Loading...