Angefangen hat es damit, dass einem Mitarbeiter seit Montag die Maschine mehr oder minder
	  zuverlaessig einfriert (Ubuntu 14). Woran das liegt, war vollkommen unklar, bekannt war nur, dass ein 
	    rm -rf $HOME/.kde
	  das Problem eine Zeitlang behebt. Vermutungen waren 
		- Defektes RAM => kann nicht sein, Problem taucht einen Rechner weiter genauso auf
		- Kernel Panic wegen Speicher/CPU Last => Logs und Statistiken sagen das Gegenteil
		- KDE Programmierfehler => Kollege mit gleicher Config hat das Problem nicht
	  Also erstmal keine Idee. Logs durchgeschaut, was sich denn in den letzten Tagen auf der
	  Maschine geaendert hat. ISC Tools? Wohl kaum. Der Linux Kernel? Seltsam.
	  Wie mir der Betroffene ein Ergebnis seiner Arbeit zeigen will
	  (in einem PDF), friert die Kiste ein. Neue Vermutung: Acroread 9 for Linux.
	  Am naechsten Rechner ausprobiert -> friert die Maschine sofort ein. 
	  Versucht, das unter Ubuntu 16.04 nachzustellen -> friert nicht ein.
	  Reboot der 14er Maschine, statt dem -140 Kern den -138 genommen -> friert nicht mehr ein.
	  Was ist der Unterschied? Die Intel Firmware und die Wuergarounds fuer die Spectre/Meltdown Bugs.
	  Welche absurden Assembler-Verenkungen der Acroread macht, dass die neue Intel Firmware zuverlaessig
	  den Rechner vollbremst, bleibt unklar, vielleicht Anti-Debugging-Obskurantismus...
	  Der Mitarbeiter hatte den Acroread als default-PDF View eingestellt, und deswegen wurde
	  der auch zum Erzeugen von Thumbnails im Filebrowser benutzt; und das KDE merkt sich, welche
	  Fenster offen sind, und deswegen...
	MERKE:
	  Der Teufel steckt im Detail und in Intel Firmware Patches.
 	  https://usn.ubuntu.com/usn/usn-3531-2/
	  

[/bauerm] permanent link