[vpn-help] Solution for Assertion `type == PTHREAD_MUTEX_ERRORCHECK_NP' failed

[Mi Re]

Hello all

I did not find a solution for the mentioned problem here, so I'm posting it.

The error seems to be related to Intel's TSX extensions and specifically 
HLE (Hardware Lock Elision). Some Broadwell and Haswell processors have 
faulty implementations of these extensions and were later disabled by 
Intel through microcode updates.

There are two possible solutions for Linux users:

Solution 1 (the easy one): Install the latest "intel-ucode" (on Arch 
Linux) or "intel-microcode" (Ubuntu) and reboot. Check for 
distribution-specific steps first. If you're lucky, iked should now run 
fine.

If the error is still present, continue reading.

Solution 2 (the not-so-easy one): You need to rebuild your glibc package 
without Lock Elision enabled. For Arch Linux, the steps are the following:

==========
$ sudo abs core
$ cp -r /var/abs/core/glibc /tmp
$ cd /tmp/glibc

( PKGBUILD: remove the line containing --enable-lock-elision with sed:)

$ sed -i '/--enable-lock-elision/d' PKGBUILD
$ makepkg
==========

You then can either install the glibc globally for your system by executing:

$ sudo pacman -U /tmp/glibc/glibc-whatever.pkg.tar.xz

or you unpack the built glibc package to some location that you like and 
use the LD_LIBRARY_PATH mechanism to override the libs used by iked 
everytime you start iked:

$ sudo LD_LIBRARY_PATH=$LOCATION_OF_UNPACKED_TAR/usr/lib iked

With that, iked should start without any problems.

Instructions for other distributions on rebuilding glibc vary, but I 
hope you got the idea of what needs to be done.

I hope I could help some other Users out there.

Thanks also to knotty66 and shuairan from the Arch User Repository.


Regards
Mike