kernel seriell debuggen

[storm]

1. CapsLock geht nicht
2. strg+alt+F1 dito
3. SysRq Befehle ebenso
4. Keine Logs

Ooh ja, komplett fest, wahrscheinlich sogar ein Käfer im Kern, wenn sysrq auch nicht mehr reagiert. Serielles Terminal oder ein selbstgebauter (debug-fähiger) kernel wären evtl. Maßnahmen, um dem Auslöser auf die Schliche zu kommen...

Ja, ich vermute auch er liegt im Kernel. Allerdings ausgelöst durch einen "nicht optimalen" freien Radeon-Treiber. WENN Du mir eine Anleitung zum debuggen mit serieller Konsole geben magst, würd ich es mal irgendwann versuchen. Linus Thorvalds hat ja neulich explizit drum gebeten, die neuen Kernel auch auf alter Hardware zu testen. Und ab 3.2 hilft mir ja auch kein radeon.modeset=0 mehr.

Kurzform:
- Zutaten: ein 2. Rechner und ein Nullmodem-Kabel (fall keins vorrätig, kannst du dir auch eins bauen aus einem normalen seriellen Kabel)
- im zu untersuchenden Kernel muss serielle Unterstützung drin sein und zwar nicht als Modul, sondern fix (hmm, für deinen Zweck muss es eigentlich nicht fix drin sein, weil du ja nicht den Boot-Vorgang selbst untersuchen willst)

Code: Alles auswählen

CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y

- /etc/inittab ergänzen mit (steht imo auch schon auskommentiert drin):

Code: Alles auswählen

S0:23:respawn:/sbin/getty -L ttyS0 9600 vt100

- /etc/securetty checken, dass ttyS0 mit drin steht
- entweder beim booten später von Hand an kernel-boot-Zeile anhängen oder gleich in die Konfiguration von grub/lilo/whatever schreiben:

Code: Alles auswählen

console=ttyS0,9600n8 console=tty0

die Übertragungsrate kannst du für das getty und ttyS0 auch höher setzen, statt 9600 zB. 57600

- auf dem Werkzeug-Rechner zB. minicom installieren und entsprechende Verbindungseinstellung schon mal herrichten
- wenn alles soweit fertig ist, beide Rechner verbinden, auf dem Werkzeug-Rechner minicom starten, den "kaputten" Rechner starten und Kernel-Parameter nich vergessen... und wenn es passt, solltest du die Kernel-Ausgabe beim Booten (nur bei fest eingebauter serieller Konsole) und danach den Anmelde-Prompt wie auf der Konsole sehen.

Wenn du den Fehler reproduzieren kannst oder weisst, dass der innerhalb einer bestimmten Zeit auftritt, brauchst du jetzt nur noch warten. Die serielle Konsole ist aber keine Garantie, dass der Fehler oder seine Ursache sichtbar wird, nur schneller als alle anderen Methoden.

ciao, storm

[1] https://www.kernel.org/doc/Documentatio ... onsole.txt
[2] http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/
[3] https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks

[cosmac]

hi,

könnte man für den Zweck auch netconsole benutzen? Das Modul ist beim Debian-Kernel dabei und Netzwerkkabel hat jeder.

[storm]

Na klar, das ist wahrscheinlich auch einfacher einzurichten. In den debugging-Tipps vom ubuntu-wiki steht allerdings, dass die bei kernel panics wenig hilfreich ist, weil sie im Fehlerfall zu lange braucht (quasi: eh der Text der panic durch den Netzwerkstack durch ist, hat der kernel alles schon gestoppt). Auf einen Versuch kann man es ja ankommen lassen.

[clue]

Mist, ich glaub so ein Nullmodemkabel hatte ich mal. Ok, gesetzt den Fall, ich habe mal an irgendeinem WE Zeit mich drum zu kümmern, sollte ich dann nicht gleich mal den 3.2er testen, weil der ja der neue longterm support Kernel ist? Und wenn ja, wo den output pasten? Bei bugs.debian oder gleich lkml?

Noch ne Frage: Ist das mit der seriellen Konsole schon so im Debian Kernel drin, oder muss ich noch stundenlang howto's lesen, um herauszufinden, wie ich den Kernel gescheit selber backe?

Auf jeden wollte ich Dir, lieber Storm und auch NAB und Cosmac danken, für die Zeit, die Ihr Euch mit meinem Problemchen schon genommen habt

[storm]

Mist, ich glaub so ein Nullmodemkabel hatte ich mal. Ok, gesetzt den Fall, ich habe mal an irgendeinem WE Zeit mich drum zu kümmern, sollte ich dann nicht gleich mal den 3.2er testen, weil der ja der neue longterm support Kernel ist?

Wie du denkst. Wenn du den Fehler (wenn es denn der gleiche Fehler ist) so besser oder überhaupt reproduzieren kannst, dann nimm den.

Und wenn ja, wo den output pasten? Bei bugs.debian oder gleich lkml?

Na erstmal hier nopasten. Du kannst natürlich auch gleich debian oder upstream wählen, aber dass hattest du ja schon vergeblich versucht. Vielleicht ist es auch nur etwas völlig Triviales, so dass du die anderen gar nicht bemühen musst. Nur noch so eine Idee: das Netzteil in dem Rechner ist wahrscheinlich ähnlich alt, oder? Hat die Grafikkarte einen extra Stromanschluss? [Hintergrund: eine ähnlich unklare Ursache für sporadische, aber seltene Abstürze war bei mir mal ein Netzteil. Das funktionierte eigentlich noch, nur als ich es prophylaktisch austauschte und aufgemacht hab, waren da so einige Kondensatoren aufgebläht]

Noch ne Frage: Ist das mit der seriellen Konsole schon so im Debian Kernel drin, oder muss ich noch stundenlang howto's lesen, um herauszufinden, wie ich den Kernel gescheit selber backe?

Auf dem kleinen Schenkelwärmer hier läuft 3.2.0-4-amd64 mit:

Code: Alles auswählen

CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y

Das sollte reichen.

Auf jeden wollte ich Dir, lieber Storm und auch NAB und Cosmac danken, für die Zeit, die Ihr Euch mit meinem Problemchen schon genommen habt

Gern geschehen.

[clue]

Nur noch so eine Idee: das Netzteil in dem Rechner ist wahrscheinlich ähnlich alt, oder? Hat die Grafikkarte einen extra Stromanschluss? [Hintergrund: eine ähnlich unklare Ursache für sporadische, aber seltene Abstürze war bei mir mal ein Netzteil. Das funktionierte eigentlich noch, nur als ich es prophylaktisch austauschte und aufgemacht hab, waren da so einige Kondensatoren aufgebläht]

OK, meine Kiste ist die Tage immer häufiger auch beim normalen surfen abgeschmiert. Das kann dann wohl nicht mehr bloß ein Weichwaren-Käfer sein:

Aufgeschraubt, GrakaLüfter und MoBoLüfter von Staub befreit, Ergebnis abgewartet: Es scheint etwas stabiler zu laufen. Was ich aber nicht machen darf ist nen Film zu glotzen + gleichzeitig irgendwas runterzuladen, sonst machts sofort die Mücke.

Fazit: Hardwaredefekt.

Ich möchte dazu sagen, dass dieser Fehler mich auch schon vor Jahren heimgesucht hat. Er trat aber besonders und überproportional häufig mit dem 3.2er und höher auf. Um ein halbwegs stabiles Laufverhalten herzustellen, musste ich mir mit radeon.modeset=0 behelfen (ging aber nur mit 2.6.32, ab 3.2 leider wirkungslos). Das hat bis vor kurzem auch sehr gut funktioniert. Allerdings scheint meine betagte hardware nun doch langsam den Geist aufzugeben. In bezug auf die Frage ob Käfer oder nicht Käfer sehe ich 2 Möglichkeiten:

1. Es handelte sich schon damals um einen Hartwaren-Käfer, der aber besonders durch den 3.2er getriggert wurde (vielleicht weil irgendwas softwareseitig anders angesprochen wurde als vorher).
2. Es handelt sich eben doch um einen softwarebug, der sich aber nun noch zu meinem hardwarebug gesellt.

Ich werde jetzt doch die GraKa nebst Nett-Zwerg-Karte austauschen. Ich hab glücklicherweise nen Kumpel, der tonnenweise alten Computerkram hortet. Da wird schon was für mich bei sein.

Dann werde ich ausgiebig auch den 3.2er testen und Euch das Ergebnis hier berichten, versprochen!

[clue]

Wie versprochen hier meine Rückmeldung:

Nachdem auch meine Festplatte anfing während des laufenden Betriebes aus und wieder an zu gehen, war für mich klar, dass es wohl am Netzteil liegen muss. Also hat mir mein Kumpel ein neues Gebrauchtes geschenkt. Seitdem sitze ich hier sogar am 3.2er Kernel OHNE radeon.modeset=0, schaue Video, lade ein Image herunter und youtube gleichzeitig herum. Das System läuft stabil Hoffentlich auch im Langzeittest.

Storm, Du hattest tatsächlich recht

Kaum zu glauben, dass mich dieser Bug schon seit Jahren quält, und er sich so einfach hätte beheben lassen. Das ist jetzt das dritte Netzteil, das ich in meine 12 Jahre alte Kiste stecke. Im Schnitt geht also alle 6 Jahre das Netzteil drauf. Ich meld mich dann wieder so gegen 2019

Nochmals Dank an Euch alle

[storm]

Na also. Freut mich, dass das Fernraten doch noch zur Lösung geführt hat.

ciao, storm