Linux Kernel Regression mit git finden

Falls man nach einem Kernel Upgrade plötzlich Probleme bekommt und googlen nicht mehr hilft, muss man ggfs. selbst herausfinden, warum nun etwas nicht mehr funktioniert. Herzlichen Glückwunsch: eine typische Kernel Regression. Zuerst laden wir einmal die neuste Kernelversion aus dem git Repository von kernel.org ins passende Verzeichnis:

cd /usr/src
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6

Zeit für einen Kaffee! Nachdem wir die etwa 600MB runtergeladen haben, sagen wir git nun, dass wir einen Fehler “bisect”-en wollen. Hierbei wird eine Binäre Suche durchgeführt, denn mehrere hundert bis tausend Kernel-Commits wollen effizient ausgetestet werden. Dafür sagt man dem Kernel, welche Version noch gut war und welche schlecht:

git bisect start
git bisect good v2.6.36
git bisect bad v2.6.37

Als nächstes kopiert man am Besten die .config Datei des alten Kernels in das aktuelle Verzeichnis und führt “make oldconfig” durch, damit man eine für diese “Zwischenversion” korrekte .config hat. Hier wird man allerlei gefragt und sollte sicherstellen, dass alle relevanten Treiber/Funktion aktiviert sind, die man grade testen möchte. Die einfachste Methode ist hier, einfach gaaaanz lange Enter zu drücken und danach per “make menuconfig” nochmal nachzuschauen. 😉

cp ../linux/.config .
make oldconfig
make menuconfig

Nun compiliert man den neuen Kernel und kopiert ihn ins /boot Verzeichnis. Man muss hier darauf achten, dass der Bootloader auch so eingestellt ist, dass genau dieser Kernel genutzt wird.

make && make modules_install && cp arch/x86/boot/bzImage /boot && reboot

Nach erfolgtem Reboot wechselt man wieder nach /usr/src/linux-2.6, testet die Funktion und legt dann fest (“git bisect good” oder “git bisect bad”), ob sie noch funktioniert oder nicht.

git bisect good
Bisecting: 2534 revisions left to test after this (roughly 11 steps)
[d3ae8562d43fe2b97d605dd67dc67bf8fa9b956a] usb: host: ehci: fix missing kfree in remove path also

So geht es dann immer weiter, bis man irgendwann den Commit gefunden hat, der den Fehler verursacht:

Bisecting: 0 revisions left to test after this (roughly 0 steps)

[1992de83e375acc789daf66b7b72a812a5235b75] USB: qcserial: Enable Diagnostics Monitor and GPS ports on Gobi 2000

In diesem Fall hatte sich in qcserial.c einfach nur die Zuordnung der Devices geändert…

4 thoughts on “Linux Kernel Regression mit git finden

  1. Oliver

    Hach ja, Gobi 2000. Schon viel Spaß mit dem gobi-loader gehabt.

    Man kann statt “gaaaanz lange Enter zu drücken” auch dieses Konstrukt verwenden:
    yes “” | make oldconfig
    Zumindest war das früher meine Lösung als ich noch jeden neuen Kernel selber gebaut hatte. Lang, lang ists her. Aber vielleicht kann ich deine Lösung hier ja irgendwann nochmal brauchen…

    Reply
  2. admin Post author

    So ad hoc leider nicht, dazu auf Deutsch zu finden ist vermutlich aber eher schwierig. Die meisten Blogs zum Thema sind nunmal auf Englisch. Du mußt wohl google bemühen…

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *