Rechner hängt sich auf, wenn kein User eingelogt ist

megamimi

Active Member
hi...

Ich hab schon wieder ein seltsames Problem (langsam wirds mir peinlich;) )

Und zwar hängt sich mein FreeBSD 4.8 immer nach einer gewissen Zeit auf, wenn kein User eingelogt ist. Man kann dann gar nichts mehr machen außer Reset drücken und neu booten. Lässt man aber einen User eingelogt, passiert sowas nicht (jedenfalls die letzten 8 Stunden nicht...). Wichtig dabei ist nur das der User an einem der lokalen Terminals eingelogt ist, ssh hilft nicht. In den Logs steht nichts, soweit ich das beurteilen kann....

An was liegt das? Ich habe das Gefühl der Rechner ist fängt einfach nach einer bestimmten Zeit, in der nichts geschiet an zu "schlafen" und wacht einfach nicht mehr auf...

Ich hoffe das Problem ist diesmal nicht so blöd wie mein letztes (Thread weiter unten...)

Danke, mimi
 
oops, erst lesen dann antworten ;-)

Lass mal ein top laufen (per ssh) und kuck mal was passiert.

ansonsten ktrace init und kucken was es vor dem hang macht
 
Zuletzt bearbeitet:
Hmm, ist im BIOS irgendwas von wegen suspend eingestellt. Das die Platten runterfahren, oder der gesammte Rechner sich in den Schlaf legt?
Evtl. kommt der dann nicht mehr hoch, das wäre dann aber kein wirklicher crash.
 
hi...

Inzwischen hab ich das Problem weiter einkreisen können: Es liegt an PPP oder natd. Wenn ich den Rechner nicht ans Inet anschließe (das Kabel zum DSL- Modem entferne) rennt der Rechner tagelang. Sobald aber eine Verbindung zustandekommt, dauert es keine 2 Stunden bis der Rechner crasht. Es könnte sich um eventuell um DoS handeln, aber mir ist keine Anfälligkeit von FreeBSD bekannt (Was nichts heißen muss;)). Ich werde jetzt mal versuchen einen neuen Kernel mit "option DDB" zu kompilieren, mal sehen was damit herauskommt.

Ich halte euch selbstverständlich auf dem Laufenden....

cu mimi
 
Also mit "option DDB" erhalte ich nach gewisser Zeit diese Meldung:
Code:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x3a
fault code          = supervisor write, page not present
instruction pointer = 0x8: 0x02b245e
stack pointer       = 0x10: 0x035ab30
frame pointer       = 0x10: 0xc035abd0
code segment        = base 0x0, limit 0xfffff, type 0x1b
                    = DPL 0, press 1, def32 1, gran 1
processor eflags    = interrupt enabled, resume, IOPL=0
current process     = Idle
interrupt mask      = net tty
Kernel: type 12 trap, code=0
Stopped at            vm_fault+0x132: addw %ax,0x3a(%edx)

Kann jemand damit was anfangen?

danke, mimi
 
Hi mimi

> Es liegt an PPP oder natd

> fault virtual address = 0x3a

Ich denke das reicht für einen Bug-Report, weil sich hier wahrscheinlich wenig Leute mit Kernel-Debuggen auskennen.

Wilde Raterei: Die Addresse 0x3a ist sehr klein, wenn's einen guten
Grund für den Kernel gibt daruf zuzugreifen (also die 0x3a nicht
zufällig ist), dan riecht das etwas nach verkonfigurierten Treibern, kaputten BIOS-Einstellungen oder fauler Hardware.

Benutzt du einen Generischen Kernel?

Wenn nein: was passiert wenn du ihn benutzt?

Wenn ja: Versuch mal einen minimalen Kernel zu bauen (wirklich alles raus, was du nicht zum reproduzieren des Bugs brauchst).

Hast du schonmal Karten rausgezogen und gekuckt ob das Problem immer noch auftritt?

Hast du einen zweiten Rechner oder ein Terminal? Wenn ja kannst du dort einen Debugger mitlaufen lassen und dir genauer ankucken wo und vielleicht warum der Kernel abschmiert, ist aber etwas aufwendig.

Grüße,

Schnoffos

PS: was war das ganz am Anfang mit dem eingeloggten User? Wenn du auf der Konsole eingeloggt bist crashed der Kernel nicht? Ist das noch so? Wenn das noch so ist, würde ich trotzdem mal ein ktrace auf init laufen lassen und nach dem crash nachschauen ob da was auffälliges passiert. Ich weiß nicht was passiert wenn init crashed, aber ich kann mir gut vorstellen das sich u.U. dann der Kernel gleich mit aufhängt. Nur ne Idee...
 
Zuletzt bearbeitet:
hallo,

Tut mir Leid wenn ich so einen alten Thread wieder aufwärme, aber ich wollte euch nur mitteilen woran es gelegen hat.

Und zwar lag es an einer kaputten Festplatte. Also kein Bug in FreeBSD sondern ein stinknormaler HW- Defekt...

cu mimi
 
Zurück
Oben