Mit "general protection fault" umgehen

  • Hallo,
    ich hab seit längerer (ich kann den Zeitpunkt nicht mehr exakt bestimmen) sporadisch (ca. einmal die Woche) das Problem, dass sich mein VDR (yavdr) mit einer einzigen Log-Zeile verabschiedet:

    Code
    general protection fault: 0000 [1] SMP


    Nun ist eine Log-Zeile nicht wirklich hilfreich bei der Fehlersuche...
    Gibt es eine Möglichkeit dem VDR mehr Debug-Information abzuringen?
    Gibt es eine Option ähnlich wie beim Kernel-Panic, dass automatisch ein reboot durchgeführt wird?



    Bis jetzt hab ich nur den Speicher und die Festplatte überprüft. Beides ist angeblich in Ordnung.
    Grüße
    Michael

    HD-VDR-EG
    Software: yaVDR-0.4
    Hardware: ASRock M3N78D, Athlon II X2 240e, ASUS EN210, TeVii s480
    HD-VDR-DG:
    Software: yaVDR-0.4
    Hardware: ASRock N68-S3 UCC, Athlon II X2 245e, ASUS EN210, TeVii s480
    ---
    Don't sleep and build!

  • Sicher das es der VDR selber ist? Wenn sich der VDR verabschiedet sollte er eigentlich automatisch neu gestartet werden.


    Da steht doch bestimmt ne PID vorne in der Zeile, daran kannst du erkennen was diese Meldung verursacht.


    Ist doch vermutlich der Kernel. Versuche mal "kernel.panic_on_oops = 1"


    cu

  • Hallo,


    sry. Ich hab mich schlecht ausgedrückt. Mit VDR meinte ich nicht den vdr-Prozess selbst, sondern den ganzen Rechner. Ich ging davon aus, das es am Kernel/Hardware liegt. Sollte nur der vdr-Prozess Mist bauen, müsste der Rechner ja noch bedienbar sein.
    Sollte bei einem Kernelfehler nicht ein "oops", "kernel panic" oder ein Stack-trace im log sein?
    Bzw. greift da die Option kernel.panic_on_oops überhaupt? Ich probier's mal aus - Versuch macht ja bekanntlich klug.


    Grüße Michael

    HD-VDR-EG
    Software: yaVDR-0.4
    Hardware: ASRock M3N78D, Athlon II X2 240e, ASUS EN210, TeVii s480
    HD-VDR-DG:
    Software: yaVDR-0.4
    Hardware: ASRock N68-S3 UCC, Athlon II X2 245e, ASUS EN210, TeVii s480
    ---
    Don't sleep and build!

  • Sollte bei einem Kernelfehler nicht ein "oops", "kernel panic" oder ein Stack-trace im log sein?


    Eigentlich ja schon, deswegen meinte ich ja "einfach mal probieren".


    Bzw. greift da die Option kernel.panic_on_oops überhaupt? Ich probier's mal aus - Versuch macht ja bekanntlich klug.


    Jup, Versuch macht klug. Wenn das auch nicht greift dann bleibt wohl keine Möglichkeit mehr das Softwaremässig abzufangen (weil das System hängt dann ja bei dir offensichtlich komplett).



    Das das System gelegentlich (ohne ersichtlichen Grund) nicht mehr bedienbar ist (trotz kernel.panic_on_oops und kernel.panic) kenne ich auch. Deswegen habe ich noch die Hoffnung das uwe67 doch noch mal nen Watchdog in yaUsbIR einbaut, damit könnte man dann so was auch noch abfangen.


    cu

  • Die gute Nachricht: Es finden jetzt nachts reboots statt.
    Die schlechte Nachricht: Es steht nichts mehr im Log. Ich hab mal die Zeit erhöht.
    Und es ist noch ein weiteres Problem aufgetreten (bzw. das ist schon bekannt): Wenn mein System hängt und man den Reset-Knopf drückt, dann hängt er beim reboot im Bios nach/beim Erkennen der Laufwerke. Drückt man den Powerknopf und wartet ca. eine Sekunde (und drückt ihn wieder) dann bootet er brav.

    HD-VDR-EG
    Software: yaVDR-0.4
    Hardware: ASRock M3N78D, Athlon II X2 240e, ASUS EN210, TeVii s480
    HD-VDR-DG:
    Software: yaVDR-0.4
    Hardware: ASRock N68-S3 UCC, Athlon II X2 245e, ASUS EN210, TeVii s480
    ---
    Don't sleep and build!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!