Linux_Kernel_panic x86 split lock detectie

Linux Mint ‘bevriest’ door x86/split lock detectie

En tijdje geleden werd ik, na update naar Linux Mint 22, geconfronteerd met een vervelend probleem: “bevriezen” van mijn computer. De enige oplossing: harde reset. Dit deed zich willekeurig voor, een paar keer per week.

(Afb. boven: William Pina, CC BY-SA 3.0, via Wikimedia Commons)

Het probleem deed zich vooral voor als ik werkte met Citrix. Op een Facebookgroep voor Linux Mint gebruikers heb ik het probleem beschreven en stukje logging meegeleverd.

Het probleem deed zich eerder ook al voor in Linux Mint 21.3, op m’n vorige desktop computer, maar was verdwenen nadat ik deze had vervangen (nieuwe PC) en helemaal up to date had gebracht. Om vervolgens terug te keren nadat ik deze had geupgrade naar Linux Mint 22!

Onderstaand een vertaalde¹) versie van de uitleg die ik kreeg van een van de mede-gebruikers en zijn oplossing. En, .. die werkt! Daarom deel ik deze hier ook.

Ik werk met een computer met een Intel CPU, maar het probleem doet zich ook voor in AMD processoren. Het komt voor in verschillende Linux-distributies, niet alleen in Linux Mint.

De fout vinden

Als eerste open je een terminal en voert in:

journalctl -b -1

Scroll door de logging heen en let op dat je verdachte meldingen bij zo’n hulpvraag meestuurt.

In mijn geval en melding over: x86/split lock detection. Als je zo’n foutmelding in Google invoert krijg je ongelofelijk veel “oplossingen” maar geen enkele oplossing die mij goed leek, bleek te werken. Dus uiteindelijk op de facebook-groep de vraag gesteld.

Wat er gebeurt en hoe je het oplost

alder lake i3 split lock error linux mint
(Mijn desktop systeem: Dell PC met Intel i3/Alder Lake)

De vastlopers worden vrijwel zeker veroorzaakt door Intel’s split-lock-detectie op Alder Lake-CPU’s (zoals jouw Core i3-12100). Citrix Workspace staat erom bekend dit type instructies te triggeren. Oudere of slecht geoptimaliseerde software zijn vaak de oorzaak van het probleem.

1. Wat betekent “split-lock detection”?

Moderne Intel-CPU’s (vanaf Ice Lake, inclusief Alder Lake zoals de i3-12100) hebben hardwarematige detectie voor split locked instructions. Deze ontstaan wanneer software een atomaire operatie (een ononderbreekbare actie: deze wordt volledig uitgevoerd of helemaal niet, zonder tussenstanden die door andere processen gezien kunnen worden.) uitvoert op een geheugenadres dat over een cache-line-grens heen gaat — iets wat:

  • Slecht is voor prestaties, en
  • Over het algemeen wordt gezien als een bug in de software of in bepaalde emulatielagen.

De Linux-kernel kan hier op verschillende manieren mee omgaan:

Modus

Gedrag

off

split locks negeren

warn

waarschuwing loggen en doorgaan

fatal

#AC beëindigt het proces, en als dit in kernelcode gebeurt kan het systeem vastlopen of in ‘kernel panic’ raken.

— In mijn geval was het dus een ‘fatal’

2. Citrix Workspace en split locks

Citrix Workspace voor Linux gebruikt instructies die split locks kunnen veroorzaken. Dit is een bekend probleem en is al meerdere keren gerapporteerd. Dat je systeem vooral vastloopt tijdens het gebruik van Citrix past hier perfect bij.

Wanneer Citrix een split-lock-instructie triggert en de kernel in fatal mode staat:

  • De CPU genereert een #AC-exception
  • Het hele systeem kan in één keer bevriezen
  • Er verschijnen geen logs, omdat de vastloper optreedt vóórdat er iets naar disk geschreven kan worden

Je logregel:

x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks

betekent dat:

  • Kernel split locks in fatal mode staan
  • User-space split locks in warn mode staan. Maar afhankelijk van de kernelconfiguratie kunnen sommige user-space split locks alsnog een crash veroorzaken.

Waarom gebeurt dit niet altijd?

Omdat split-locked instructies alleen onder specifieke omstandigheden optreden, bijvoorbeeld afhankelijk van:

  • Specifieke Citrix rendering-paden (of andere software!)
  • De inhoud van de remote desktop
  • Grafische acceleratie
  • Versies van libicu of GTK
  • CPU-microcode-updates

Daardoor kan het zijn dat alles wekenlang probleemloos werkt, en je daarna ineens herhaaldelijk precies dat foute codepad raakt.

Hoe los je dit op? (3 werkende oplossingen)

Oplossing 1 — Split-lock-handhaving uitschakelen (aanbevolen)

Voeg de volgende kernelparameter toe:

split_lock_detect=off

Zo doe je dat in Linux Mint:

  1. Bewerk de standaard GRUB-configuratie:
    sudo nano /etc/default/grub
  2. Zoek deze regel:
    GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”
  3. Verander dit naar:
    GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash split_lock_detect=off”
  4. Update GRUB:
    sudo update-grub
  5. Herstart het systeem.

Hiermee vertelt je kernel om split-lock-events volledig te negeren. Dit is veilig voor 99,9% van desktopgebruikers. Het enige nadeel is dat je CPU je niet langer waarschuwt voor deze zeer obscure bugs.

Oplossing 2 — Overschakelen naar “warn” in plaats van “fatal”

Als je het niet volledig wilt uitschakelen:

split_lock_detect=warn

Hiermee wordt het probleem gelogd, maar bevriest het systeem niet. Een andere oplossing is een oudere Citrix-versie installeren, mits die te vinden is. De bug komt echter in veel versies voor en split-lock-detectie uitschakelen blijft de meest betrouwbare oplossing.

Gekozen oplossing

In eerste instantie heb ik gekozen voor de ‘warn’ oplossing (oplossing 2). Dit ging lange tijd goed tótdat ik recent mijn Linux-updates uitvoerde: de vastlopers kwamen incidenteel weer voor. Daarom heb ik nu gekozen voor “off”. En hoop dat ze nu voor altijd weg zullen blijven.

_____________________
¹) vertaling en opmaak van dit artikel door ChatGPT

Delen op: