group.of.nepali.translators team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

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 नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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