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…