Kernel-Entwickler David Jones hat sich seit einiger Zeit mit einem komplizierten Bug herumgeschlagen, der seit Kernel 3.17 existiert und den die Entwickler auch bis zum Release der Version 3.18 nicht beheben konnten.
In einem Blogeintrag gibt der Entwickler, der demnächst von Red Hat zu Akamai wechselt, Einblick in die vorläufige Lösung des Lockup-Problems. Demnach habe man zunächst in verschiedenen Bereichen, etwa im Watchdog-Code, Scheduler, Page Fault Handling nach der Ursache des Bugs gesucht und sei dabei auf verschiedene andere kleinere Probleme gestoßen, die aber das Lockup-Problem nicht gelöst hätten.
In der letzten Woche bevor Jones seine Hardware zurück an Red Hat geben wollte, habe Linus die Probleme mit einer gewissen Wahrscheinlichkeit reproduzieren können, indem er direkt von “/dev/mem” in den High Precision Event Timer Offset (HPET) schrieb. Unklar blieb, warum etwas in “/dev/hpet” schreiben kann, weil der Node keine direkten Schreibzugriffe erlaubt, nicht einmal mit Root-Rechten.
Jones zog als zwei mögliche Urheber des Problems Trinity, seinen Systemcall Fuzz Tester, und einen Hardware Bug in Betracht. Im ersten Fall hätte Trinity zufällig eine bestimmte Adresse erzeugt und diese an einen System Call weitergereicht, der darin geschrieben hätte. Das Szenario ließ sich allerdings nicht reproduzieren. Im zweiten Szenario führt dank eines Hardware Bugs die CPU-Load dazu, dass der HPET sich selbst korrumpiert. Jones habe nach dem DMI String der betroffenen Maschine gesucht und sei auf einen anderen Bugreport gestoßen, der ähnliche Probleme aufweise.
Ein Patch von Linus Torvalds scheint das Problem am Ende behoben zu haben, ohne dass die Entwickler dessen Ursache wirklich gefunden haben. Mit ihm lief der Testrechner von Jones über längere Zeit stabil.
