Kernel Trap - Fehler richtig debuggen und melden

cryptosteve

cryptosteve

Ex-Steve`
Moin,

ich kämpfe immer noch mit meinem Notebook und dem FreeBSD darauf. Das Powermanagement funktioniert nun, nachdem mir jemand einen Patch gebaut habe, mit Hilfe dessen ich mir eine neue /boot/DSDT.aml bauen konnte.

Nach wie vor friert das Notebook jedoch nach einiger Zeit ein. Oftmals habe ich gar keine Fehlermeldung bekommen, sondern einfach nur keine Reaktion mehr. Zuletzt habe ich mit "verbose logging" gebootet und dabei folgenden Kernel-Trap gesehen:
Code: 
Fatal trap 18: integer divide fault while in kernel mode
instruction pointer             = 0x20:0xc081d9d9
stack pointer                   = 0x28:0xd9fcabd0
frame pointer                   = 0x28:0xd9fcabdc
code segment                    = base 0x0, limit 0xfffff, type 0x1b
                                = DPL 0, pres 1, def32 1, gran 1
processor eflags                = interrupt enabled, IOPL = 0
current process                 = 1043 (bsdtar)
trap number                     = 18
panic: integer divide fault
Uptime 18m48s
Ok, Fehler Nr. 1 .. es war kein dumpdevice angegeben. Das werde ich jetzt nachholen. Leider fehlt mir für weiteres Vorgehen ein bißchen die Clue. Nach welchen Stichworten muß ich suchen?! gdb? Gibt es irgendwo eine leicht verständliche Anleitung für Kerneldebugging? Wie sollte ich vorgehen, wenn ich den Fehler melden möchte?! Gibt es ein Mindestmaß an Informationen, die ich mitliefern soll, oder sollte ich den Fehler zunächst einfach so melden und dann die Reaktion der Kernelspezialisten abwarten?!
 
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html

Da steht eigentlich alles. Wenn Du weitere Fragen hast, immer her damit.
Ich habe mir zwei Nullmodemkabel gekauft, damit lässt sich komfortabel remote Debuggen (Aber vermutlich hat dein Notebook nichtmal mehr eine serielle Schnittstelle).

HTH
Male

P.S. Achte drauf, dass auf dem dumpdevice genug Platz ist; und auch unter /var/crash. Und das du den Kernel und die Module mit Debuginformationen baust.
 
Ok, das Dumpdevice ist groß genug. Jetzt muß ich mal gucken, ob und wie ich den Kernel mit den notwendigen Debuginformationen bau. Wenn ich mich recht erinnere, sind die entsprechenden Optionen im 6.0-RC1-Kernel noch enthalten. Aber da schaue ich nochmal nach.

Wenn ich
Code: 
# cd /usr/obj/usr/src/sys/KERNCONF
richtig deute, muß ich den Kernel aber selber bauen, oder? Ich weiß gar nicht, ob ich beim Notebook überhaupt soweit komme. :(

Danke erstmal für Deinen Hinweis.
 
So, eben hat sich das Notebook unter ACPI wieder weggehängt. Diesesmal leider völlig ohne Fehlermeldung und ohne dump.

Toll, nech? :(
 
Check mal die Hardware. Ich hab mir letztens einen SO-DIMM-Riegel gekauft, der nicht so ganz mit dem Thinkpad hier funktioniert hat.

Aufgefallen ist es mir in Deutschland hier nicht (ich glaube, es gab nur zwei mal ungeklärte Probleme, die ich nicht zuordnen konnte). In Indonesien ist aber fast immer 35°C im Schatten. Da machte das Notebook etwa 10 Minuten mit, dann gab es Panics aus verschiedenen Gründen.

Bei derart oft vorkommenden Panics würde ich immer auf die Hardware tippen. Da kannst Du mir auch nicht mit einem "Win* läuft aber problemlos" kommen. Solche Aussagen sind für mich irrelevant, weil ich schon Pferde kotzen gesehen habe bei Win*.
 
Windows ist nicht drauf, aber auf einer anderen Platte im gleichen Notebook läuft Linux ohne weitere Probleme.

Nichts desto trotz könnte die Idee brauchbar sein. Es stecken zwei Hauptspeicherriegel drin, ich werde die mal abwechselnd einzeln testen.

Testweise zu dem o.g. Problem hatte ich bsdtar auch schonmal gelöscht und stattdessen die Version aus den Ports benutzt. Das Notebook bleibt trotzdem hängen und nicht immer bei bsdtar-Aufrufen. Ich werde weiter berichten.
 
war auch mein Gedanke, aber ich habe mich schon öfter an alberne Strohhalme geklammert, die dann letztlich zum Ziel geführt haben.

Ich will dem Ergebnis ja auch nicht vorausgreifen, aber nachdem ich einen 256MB-Riegel ausgebaut habe, läuft mein portsnap extract schon seit 34 Minuten (inkl. Boot) ohne Absturz. So lange hat die Kiste noch nie durchgehalten.
 
Hallo Steve`,

kennst Du zwar bestimmt,
aber ich poste mal Links zu Bootfähigen Memtest Tools:
memtest86
memtest86+

Kann man ein fertiges Bootfähiges CD-Image fetchen,
auf CD brennen, damit booten,
und dann damit den Arbeitspeicher testen. ;)


Gruß, Fusselbär
 
Wow, super. Nein, kannte ich noch nicht. memtest86 hatte ich zuletzt auf meiner SuSE8.0-CD gehabt und danach nie wieder so recht zu sehen bekommen. Das werde ich mal mit meinem einen (fragwürdigen) Chip testen.
 
Memtest86 spinnt allerdings auf einigen Mainboardchipsätzen extrem. Zum Beispiel hat er auf meinem nforce4 Prof. hunderte Fehler gefunden, obwohl die Riegel einwandfrei sind.
 
Mein Notebook läuft einwandfrei unter FreeBSD 6.1-RC1, sobald ich einen Speicherchip rausnehmen und nur noch auf 256MB fahre. Dabei ist es egal, welchen von beiden Speicherriegeln ich aktiv im System lasse. Frag mich jetzt nicht, wo genau das Problem liegt.

Jetzt wäre fast alles super. Aber leider kriege ich meine NetGear-WG511 WLAN-PCMCIA-Karte nicht zum Laufen. Den Treiber (pff) bekomme ich nicht so recht kompiliet, ein fremdes Modul läßt sich zwar laden, tut aber nichts. Ich weiß jetzt noch nicht ganz, ob ich zu blöde dafür bin oder obs wirklich nicht geht, weil ich hie an zwei neuen Fronten kämpfe (FreeBSD/pcmcia und FreeBSD/WLAN).

Gibts hier jemanden, der 'ne WG511 unter FBSD betreibt?
 
Steve` schrieb:
Mein Notebook läuft einwandfrei unter FreeBSD 6.1-RC1, sobald ich einen Speicherchip rausnehmen und nur noch auf 256MB fahre.
Zum Vergrößern anklicken....
Das war leider ein Irrtum. Ich mußte soeben feststellen, dass FreeBSD in den unterschiedlichsten Teilprogrammen 'coredump't (bsdtar, awk, idle, etc.), sobald ich dem Prozessor mal richtig Last zumute. Ich hatte versucht, einen neuen Kernel zu bauen, konnte dieses Vorhaben aber meistens schon nach wenigen Sekunden/Minuten vergessen.

Egal, ich gebs auf. FreeBSD mag mit meinem Notebook offenbar nicht; Linux hingegen funktioniert inkl. WLAN zufriedenstellend ... dann bleibt es halt dabei.
 
Falls Memtest86 oder Memtest86+ nicht mit dem Chipsatz will

OOZE schrieb:
Memtest86 spinnt allerdings auf einigen Mainboardchipsätzen extrem. Zum Beispiel hat er auf meinem nforce4 Prof. hunderte Fehler gefunden, obwohl die Riegel einwandfrei sind.
Zum Vergrößern anklicken....

Hallo OOZE,

falls weder Memtest86 noch Memtest86+ den Chipsatz mögen,
da gibt es noch was von Microsoft:
Windows Memory Diagnostic (aka windiag)

Windows Memory Diagnostic macht das Gleiche,
wie die Memtests,
es testet den Arbeitspeicher.

Villeicht kommt das ja beser mit dem Chipsatz zurecht.
Ist aber ein ISO-Image, welches in eine Windows-EXE eingepackt ist.
Die Windows-EXE ist mehr als doppelt so groß,
wie das ausgepackte bootfähige ISO-Image. :ugly:

Aber ich fürchte,
man darf das vom Klimbim bereinigt fertige ISO-Image
wohl nicht einfach so weitergeben.
Also irgendwo ein Windows benutzen, zum auspacken.
Ob es mit Wine klappt, habe ich nicht ganz durchgetestet,
da fehlte gleich im ersten Anlauf die MFC42.DLL.
Hatte dann keine Lust, die zu implantieren.


Gruß, Fusselbär

Nachtrag:
Hoppla,
auf der oben angegebenen Microsoft Seite funktioniert der Downloadlink nicht:
Man wird von dort aus in die Irre geführt.
Ein beherztes
Code: 
fetch http://oca.microsoft.com/en/mtinst.exe
macht dann das, was die Micosoft Webseite nicht schafft. :D
 
Zuletzt bearbeitet:
Hast du es schonmal ohne ACPI probiert? Es ist eher unwahrscheinlich das es was bringt, aber wer weiß... :ugly:
 
Ja, natürlich hatte ich es schon ohne ACPI versucht. Bringt leider nichts. Eigentlich hab ich schon alles versucht, was mir irgendwie einfiel. :(
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben