NVIDIA's Latest Binary Driver Is Causing Problems For Some Skylake Linux Users

[phoronix]

Phoronix: NVIDIA's Latest Binary Driver Is Causing Problems For Some Skylake Linux Users

It seems that NVIDIA's proprietary Linux graphics driver is having some bad interaction issues with the newest Intel Skylake systems...

http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-SKL-Latest-Woes

[blackout23]

Some of these reports look like the segfault is because the application can't locate NVIDIAs Wayland EGL implementation.

[magika]

Its the other way around, HLE bug in processor causes crashes and not the NVIDIA blob. I am the author of the first linked thread and crashes occur even when runninig on Iris Pro without blob installed. People in first thread dont even mention NVIDIA blob.

[milkylainen]

So it's actually what it has always been then? Broken intel drivers?

[duby229]

So it's actually what it has always been then? Broken intel drivers?

It's looking like it may be errata either in hardware or firmware. But, it may be possible for Intel to work around it in drivers. So far it seems related to state changes in the Speedstep implementation.

[raonlinux]

So far none problem to me with intel 6600k and nvidia 750 ftw, using drivers 352 on archlinux.

[miah]

I had this problem on a fresh Arch install with a i7-6700k and a GTX 980 Ti. As mentioned in one of the threads, rebuilding the glibc package without --enable-lock-elision resolved the issue for me. Hopefully we'll get a microcode update before too long.

[FuturePilot]

Funny how people always want to blindly blame proprietary drivers

[ynsta]

Same bug for me with a Core i5-6600K and NVIDIA GM204 [GeForce GTX 970]
NVIDIA drivers 352.41 on 4.1.6-1-ARCH x86_64 (64 bit gcc: 5.2.0).

For example with vlc :

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79af7e0 in __lll_unlock_elision () from /usr/lib/libpthread.so.0
(gdb) bt
#0 0x00007ffff79af7e0 in __lll_unlock_elision () from /usr/lib/libpthread.so.0
#1 0x00007ffff1fb726c in ?? () from /usr/lib/libEGL.so.1
#2 0x00007ffff1f47a22 in ?? () from /usr/lib/libEGL.so.1
#3 0x00007fffffffd4e0 in ?? ()
#4 0x00007ffff1fcbea1 in ?? () from /usr/lib/libEGL.so.1
#5 0x00007fffffffd4e0 in ?? ()
#6 0x00007ffff7def3b6 in _dl_close_worker () from /lib64/ld-linux-x86-64.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I hope Intel will soon release a microcode data file for skylake.

Waiting for the release the glibc and lib32-glibc rebuild without the --enable-lock-elision works fine.

sudo pacman -Sy abs
sudo abs
mkdir /tmp/abs
cd /tmp/abs
cp -r /var/abs/core/glibc .
cp -r /var/abs/multilib/lib32-glibc .
sed -i.orig '/--enable-lock-elision/d' glibc/PKGBUILD
sed -i.orig '/--enable-lock-elision/d' lib32-glibc/PKGBUILD
cd glibc
gpg --keyserver pgp.mit.edu --recv-keys 25EF0A436C2A4AF # if not already imported
makepkg -ci
cd ../lib32-glibc
makepkg -ci

[gigaplex]

I had this problem on a fresh Arch install with a i7-6700k and a GTX 980 Ti. As mentioned in one of the threads, rebuilding the glibc package without --enable-lock-elision resolved the issue for me. Hopefully we'll get a microcode update before too long.

Wait, is this a repeat of TSX being a faulty instruction from the Haswell era that Intel eventually disabled?