Hello Jason, or anyone else affected, Accepted llvm-toolchain-3.8 into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/llvm- toolchain-3.8/1:3.8-2ubuntu3 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Also affects: mesa (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: llvm-toolchain-3.8 (Ubuntu Xenial) Importance: Undecided Assignee: Timo Aaltonen (tjaalton) Status: In Progress ** Changed in: llvm-toolchain-3.8 (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags added: verification-needed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1564156 Title: xenial: invalid opcode when using llvmpipe Status in OEM Priority Project: New Status in System76: Triaged Status in llvm-toolchain-3.8 package in Ubuntu: Fix Committed Status in mesa package in Ubuntu: New Status in llvm-toolchain-3.8 source package in Xenial: Fix Committed Status in mesa source package in Xenial: New Bug description: Currently it's impossible to install from xenial-desktop-amd64.iso on a wide range of hardware with Nvidia GPUs. The problem is invalid opcode(s) when using llvmpipe (the software opengl fallback, used when using Unity with the Nouveau driver). The result is that compiz crashes over and over; Upstart will continue to restart compiz till it gives up. To confirm whether this bug is happening, switch to a VT and check dmesg, in which you'll see something like: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 A workable solution seems to be to re-build mesa against llvm-3.6-dev, libclang-3.6-dev (rather that 3.8). This would get us a working Xenial ISO for the effected hardware. Post 16.04 release, this could be revisited, and mesa in Xenial could possibly switch back to llvm 3.8 once this issue is resolved. I have mesa test packages built against llvm 3.6 here: https://launchpad.net/~jderose/+archive/ubuntu/mesa/+packages I couldn't test the installation without a re-spun ISO, but I did confirm that after updating to the mesa packages in my PPA, I could again use Unity. So I'm pretty sure this will fix installing from the ISO as well. My hunch is that llvm 3.8 is generating invalid code during its JIT compilation for llvmpipe, but it could also be the result of memory corruption. Either way, building mesa against llvm 3.6 seems to be quick the fix. Note this is a regression from 14.04.4 and 15.10, both of which install fine on the hardware effected by this bug. For concrete examples of System76 hardware effected by this: 1) All Skylake laptops with 970m, 980m, and 980gtx GPUs 2) All Skylake and Haswell-E desktops with 970gtx and 980gtx GPUs (although strangely, things seem to work with when you connect to a monitor over HDMI, but always fails when connecting to a monitor over DisplayPort) Note that none of the above failed tested scenarios are using Optimus: all are using discrete GPU configurations. In my testing thus far on the effected hardware, the install always fails if you choose "Try Ubuntu without installing". The install usually seems to work when you choose "Install Ubuntu", but even this 2nd scenario sometimes fails (and when it does, you'll see the same "trap invalid opcode" bits in dmesg). Also note that so far I've only tested amd64, haven't tested i386. I suspect there is some deeper weirdness here, but at this point System76 is just trying to make sure we have a Xenial ISO from which customers can re-install Ubuntu. Old description =============== Currently Unity on Xenial is unusable when the llvmpipe software fallback is used, at least on certain hardware. For example, from dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 [ 2093.109485] traps: compiz[10192] trap invalid opcode ip:7f38ac01a0d4 sp:7ffe5ed737e0 error:0 [ 2093.718863] traps: compiz[10212] trap invalid opcode ip:7fe6900010d4 sp:7ffd55804020 error:0 This definitely effects hardware we've tested with NVIDIA 970m and 980m GPUs (when using the nouveau driver), and probably effects others as well. Although strangely, with some NVIDIA 900 series hardware we're not seeing this bug when using the nouveau driver. This will be investigated further. In the current state, it's not possible to install Xenial on effected hardware using recent daily desktop amd64 ISOs. Note this problem exists both when run against mesa 11.1.2-1ubuntu2 in Xenial proper, and when run against mesa 11.2.0~rc4-1ubuntu0.1 from ppa:canonical-x/x-staging. (The later test was done with the System76 imaging system using an image with ppa:canonical-x/x-staging and nvidia-361 pre-installed, then removing nvidia-361 and rebooting). I'm kinda shooting in the dark here, but I did my best to rule out the kernel as a variable: (1) I built and installed the 4.4.0-16 kernel on 15.10, rebooted, and had no problems. (2) On Xenial I tried the 4.5 and 4.6rc1 mainline builds, but they don't fix the problem. I'm not sure the underling bug is in compiz, but I'm filing it against compiz anyway because that's where the dmesg output is pointing me. Other likely culprits include nux, mesa, maybe even llvm, and probably others I'm not thinking of :) Also, I'm positive llvmpipe is being used when this invalid opcode is trapped because I added this to /etc/X11/Xsession.d/50_check_unity_support: /usr/lib/nux/unity_support_test -p > /tmp/compiz-debug.log That way I could figure out what renderer was being used from a VT (as the X session is darn near unusable in this state). To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1564156/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
