Results 1 to 6 of 6

Thread: Crash on __lll_unlock_elision

  1. #1

    Default Crash on __lll_unlock_elision


    I've a crash in an application on a mutex lock:
    Thread #4 4802 [core: 0] (Suspended : Signal : SIGSEGV:Segmentation fault)
        __lll_unlock_elision() at 0x7fffe4ce5940
        boost::posix::pthread_mutex_unlock() at pthread_mutex_scoped_lock.hpp:62 0x4a79b4
        boost::mutex::unlock() at mutex.hpp:76 0x4a79b4
        boost::unique_lock<boost::mutex>::~unique_lock() at lock_types.hpp:331 0x4a9a9b
        function calling boost::unique_lock<boost::mutex> locker(mutex)
        <...more frames...>
    From what I've seen this may be an issue with processor microcode and can be fixed enabling early microcode updates, unfortunately the documentation I found is for archlinux, then, does anybody know if there is a way doing the same in Leap 15.

    For information, I searched for an equivalent for Leap 15 grub method and found a line that may be the one on which we can load the microcode updates:
    echo    'Loading initial ramdisk ...'
    initrdefi /boot/initrd-4.12.14-lp150.12.48-default
    Is it the one ? Anyway, unfortunately I can't find what I should add for microcode updates load, is it one of the many files in /lib/firmware/intel-ucode (I have an Intel CPU) ?


  2. #2
    Join Date
    Jun 2008
    San Diego, Ca, USA
    Blog Entries

    Default Re: Crash on __lll_unlock_elision

    On all current openSUSE versions including LEAP 15, a current package containing CPU microcode updates is installed by default so you should be getting the recommended updates for your hardware already.

    In my case (verifying functionality for virtualization apps), there is some kind of way to probe the kernel for whether the microcode patch has opened the functionality or not.

    Consider also that microcode updates are very CPU and vendor specific, even Intel kernels have greatly progressed on what can be patched with each new CPU release. If your CPU doesn't support that microcode API, then you may be SOL.

    Beginner Wiki Quickstart -
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  3. #3

    Default Re: Crash on __lll_unlock_elision

    Not sure I understand something else that I'm doomed ? Or is there another lead that microcode on this issue ?

  4. #4

    Cool Re: Crash on __lll_unlock_elision

    Ok, fixed it, best... way... ever, since the application is a Qt application I replaced the boost::mutex by a QMutex and it does not crash anymore
    By the way, there are several other mutexes in the application that do not lead to a __lll_unlock_elision crash, in any case, the mystery remains !

  5. #5

    Default Re: Crash on __lll_unlock_elision

    Package "ucode-intel".

    ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs
    This package contains the microcode update blobs for Intel x86 and x86-64 CPUs.
    You may force install older version (and disable updates for this package).
    See "Single package Vendor change"

    Also BIOS fiirmware contains microcode updates. So maybe installing an older BIOS fiirmware can update microcode to an older version.

  6. #6

    Default Re: Crash on __lll_unlock_elision

    Thanks Svyatko,

    I just looked at your answer since for now I had no more this issue, but I found another in the application, then, starting from the ucode-intel package, do you know if there is one version that in know working, and also, but this is another story and especially if it does the job, do you know if we can specify a package version to install with autoyast ?

    Thanks again.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts