Hallo, mal wieder was neues. Beim Runterfahren bleibt meine Kiste manchmal hängen. Die Grafik schaltet beim shutdown um, es geht nicht mehr weiter. Der Bildschirm wird schwarz, der Monitor geht allerdings nicht in den Sparmodus. In /v/l/m steht was über nepomuk "Mar 31 22:30:05 Eleonora kernel: nepomukservices[5283]: segfault at 4 ip b7d43912 sp bff652f0 error 4 in libQtCore.so.4.4.3[b7cf8000+221000]" Beim erneuten Boot kommt beim Start von KDE "Es ist ein Problem beider Einrichtung der Kommunikation zwischen den KDE-Prozessen aufgetreten. Die Meldung des System lautete: Could not open network socket. Bitte vergewissern Sie sich, dass dcopserver läuft." Der DCOPServer scheint wirklich nicht zu laufen. So wie es aussieht, ist dieser Fehler mit nepomuk nicht wirklich reproduzierbar. Andere Fehlermeldungen (vorheriger shutdowns) betreffen z.B. fglrx und atieventd. Also Grafischkarte. Wenn ich statt "shutdown -h" ein init 0 mache, habe ich das Problem des Hängenbleibens nicht beobachtet. Kann das Zufall sein oder wo liegen die Unterschiede zwischen den beiden Methoden? Mal wieder ein Problem, das die Welt nicht braucht. Joachim mit OS11.1 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Mittwoch 01 April 2009 glaubte Joachim Hussong zu wissen:
Beim Runterfahren bleibt meine Kiste manchmal hängen. Die Grafik schaltet beim shutdown um, es geht nicht mehr weiter. Der Bildschirm wird schwarz, der Monitor geht allerdings nicht in den Sparmodus.
In /v/l/m steht was über nepomuk
"Mar 31 22:30:05 Eleonora kernel: nepomukservices[5283]: segfault at 4 ip b7d43912 sp bff652f0 error 4 in libQtCore.so.4.4.3[b7cf8000+221000]"
Beim erneuten Boot kommt beim Start von KDE
"Es ist ein Problem beider Einrichtung der Kommunikation zwischen den KDE-Prozessen aufgetreten. Die Meldung des System lautete: Could not open network socket. Bitte vergewissern Sie sich, dass dcopserver läuft."
Der DCOPServer scheint wirklich nicht zu laufen.
So wie es aussieht, ist dieser Fehler mit nepomuk nicht wirklich reproduzierbar. Andere Fehlermeldungen (vorheriger shutdowns) betreffen z.B. fglrx und atieventd. Also Grafischkarte.
Wie wäre es, wenn du diese Zeilen auch hier reinsetzen würdest? Evtl. kann man da ein Muster erkennen oder irgendwas, was auf die Ursache hindeutet. Vielleicht taucht auch schon ein paar Zeilen vorher was relevantes auf. Ein kurzes googeln nach "linux segfault error 4" hat da verschiedenste Ursachen zum Vorschein gebracht. Evtl. ist auch interessant: welchen Kernel hast du? Mensch Kinners, wir können nicht auf eure Rechner schauen. Das könnt nur ihr. Also: nicht etwas von "Programm blabla sagt Fehler" sondern die genaue Fehlermeldung her. Nur mit der kommt man weiter.
Wenn ich statt "shutdown -h" ein init 0 mache, habe ich das Problem des Hängenbleibens nicht beobachtet. Kann das Zufall sein oder wo liegen die Unterschiede zwischen den beiden Methoden?
Mal wieder ein Problem, das die Welt nicht braucht.
32bit und 64bit gemischt? flo -- Deine paedagogischen Lernmethoden weichen nicht sonderlich von dem Stand eines Kleinkindes ab. Um es auf den Punkt zu bringen: Dein ganzes Auftreten zeugt von einer beleidigenden und unverschaemten Weise, die nicht unkritisch stehen gelassen werden kann. [Frank Toennes in dag°] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Moin Flo, Florian Gross schrieb:
Mensch Kinners, wir können nicht auf eure Rechner schauen. Das könnt nur ihr.
Also: nicht etwas von "Programm blabla sagt Fehler" sondern die genaue Fehlermeldung her. Nur mit der kommt man weiter.
Die genaueste Fehlermeldung, die ich finden konnte, habe ich hier angegeben. Die anderen, die ich erwähnt habe sind eher unspezifisch. Ich habe im Moment keinen Zugriff darauf und kann den genauen Wortlaut nicht angeben. Das was in der /v/l/m steht ist aber genau nach dem Motto "fglrx hat Fehler" oder "atieventd hat Fehler". Meine Hauptfrage (siehe Subject) war eher die folgende
Wenn ich statt "shutdown -h" ein init 0 mache, habe ich das Problem des Hängenbleibens nicht beobachtet. Kann das Zufall sein oder wo liegen die Unterschiede zwischen den beiden Methoden?
Mal wieder ein Problem, das die Welt nicht braucht.
32bit und 64bit gemischt?
reines 32bit OS auf 64bit Hardware. Meine 11.1 ist aktuell und hat alle angebotenen Patches. Ich denke mal, mein Problem fällt in folgenden Kategorie http://bugs.kde.org/show_bug.cgi?id=183500 Dennoch bleibt die Frage, warum ein init 0 sicher runter fährt und ein shutdown *manchmal* hängen bleibt. Zufall oder begründbar? Joachim -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Freitag 03 April 2009 glaubte Joachim Hussong zu wissen:
Florian Gross schrieb:
Mensch Kinners, wir können nicht auf eure Rechner schauen. Das könnt nur ihr.
Also: nicht etwas von "Programm blabla sagt Fehler" sondern die genaue Fehlermeldung her. Nur mit der kommt man weiter.
Die genaueste Fehlermeldung, die ich finden konnte, habe ich hier angegeben. Die anderen, die ich erwähnt habe sind eher unspezifisch. Ich habe im Moment keinen Zugriff darauf und kann den genauen Wortlaut nicht angeben. Das was in der /v/l/m steht ist aber genau nach dem Motto "fglrx hat Fehler" oder "atieventd hat Fehler".
Das wäre sehr mager.
Meine Hauptfrage (siehe Subject) war eher die folgende
Wenn ich statt "shutdown -h" ein init 0 mache, habe ich das Problem des Hängenbleibens nicht beobachtet. Kann das Zufall sein oder wo liegen die Unterschiede zwischen den beiden Methoden?
Mal wieder ein Problem, das die Welt nicht braucht.
32bit und 64bit gemischt?
reines 32bit OS auf 64bit Hardware.
Ok, Mischmasch von Programmen und libraries sollte ausscheiden.
Meine 11.1 ist aktuell und hat alle angebotenen Patches.
Ich denke mal, mein Problem fällt in folgenden Kategorie
Autsch.
Dennoch bleibt die Frage, warum ein init 0 sicher runter fährt und ein shutdown *manchmal* hängen bleibt. Zufall oder begründbar?
Also wäre interessant, was da anders ist. Ich werfe da mal eine Idee in den Raum: die Prozesse werden in einer etwas anderer Reihenfolge beendet, und je nach dem wie viele und welche Prozesse laufen, wird ein Prozess beendet, ein anderer braucht aber noch was von dem. Irgendwie so. Ok, jetzt zerpflückt mal schön meine Idee. ;-) flo --
Und wenn die Sonn' noch zehnmal untergeht, Wolfhart alleine auf dem Schlachtfeld steht. Weil er tot ist, aber zu blöd zum Umfallen. [Wolfhart Willimczik und Dieter Bruegmann in dag°] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
n'abend Florian Gross schrieb:
Die genaueste Fehlermeldung, die ich finden konnte, habe ich hier angegeben. Die anderen, die ich erwähnt habe sind eher unspezifisch. Ich habe im Moment keinen Zugriff darauf und kann den genauen Wortlaut nicht angeben. Das was in der /v/l/m steht ist aber genau nach dem Motto "fglrx hat Fehler" oder "atieventd hat Fehler".
Das wäre sehr mager.
OK, ein bisschen mehr kommt schon. Apr 3 19:21:37 Eleonora kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22) Apr 1 22:18:35 Eleonora kernel: atieventsd[4497]: segfault at 548 ip b7e01a50 sp bfe31e40 error 4 in libX11.so.6.2.0[b7dbc000+12f000]
Meine Hauptfrage (siehe Subject) war eher die folgende
Wenn ich statt "shutdown -h" ein init 0 mache, habe ich das Problem des Hängenbleibens nicht beobachtet. Kann das Zufall sein oder wo liegen die Unterschiede zwischen den beiden Methoden?
Mal wieder ein Problem, das die Welt nicht braucht.
32bit und 64bit gemischt?
reines 32bit OS auf 64bit Hardware.
Ok, Mischmasch von Programmen und libraries sollte ausscheiden.
Gestern z.B. fuhr er korrekt runter. Gleich probier ich es wieder
Also wäre interessant, was da anders ist.
Ich werfe da mal eine Idee in den Raum: die Prozesse werden in einer etwas anderer Reihenfolge beendet, und je nach dem wie viele und welche Prozesse laufen, wird ein Prozess beendet, ein anderer braucht aber noch was von dem. Irgendwie so.
möglich. Das ist aber schwer zu fassen.
Ok, jetzt zerpflückt mal schön meine Idee. ;-)
flo
*rupf* Ich werde nepomuk updaten, da gibt es eine neuer Version und mal das Workaround des angegebenen Bugs anwenden. Mal sehen, ob das Problem so verschwindet wie es kam, nämlich von jetzt auf nachher. n8 Joachim -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Freitag 03 April 2009 glaubte Joachim Hussong zu wissen:
Florian Gross schrieb:
Die genaueste Fehlermeldung, die ich finden konnte, habe ich hier angegeben. Die anderen, die ich erwähnt habe sind eher unspezifisch. Ich habe im Moment keinen Zugriff darauf und kann den genauen Wortlaut nicht angeben. Das was in der /v/l/m steht ist aber genau nach dem Motto "fglrx hat Fehler" oder "atieventd hat Fehler".
Das wäre sehr mager.
OK, ein bisschen mehr kommt schon.
Apr 3 19:21:37 Eleonora kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)
Apr 1 22:18:35 Eleonora kernel: atieventsd[4497]: segfault at 548 ip b7e01a50 sp bfe31e40 error 4 in libX11.so.6.2.0[b7dbc000+12f000]
ARGH! Google mal nach "mtrr allocation failed" (evtl noch (-22) mit reinnehmen). Nach (sehr) kurzem googeln meinerseits würde das eher auf Probleme mit dem Treiber der GraKa hindeuten. Was dann evtl. auch eine Erklärung wäre, warum der segfault oben in libX11.so.6.2.0 auftritt.
Meine Hauptfrage (siehe Subject) war eher die folgende
Wenn ich statt "shutdown -h" ein init 0 mache, habe ich das Problem des Hängenbleibens nicht beobachtet. Kann das Zufall sein oder wo liegen die Unterschiede zwischen den beiden Methoden?
[...]
Gestern z.B. fuhr er korrekt runter. Gleich probier ich es wieder
Probiere mal aus, ob es einen Unterschied bedeutet, wenn du a. sehr viele Prozesse (vor allem auch große, ressourcenfresende) b. sehr wenige Prozesse laufen hast. Vielleicht ist das Problem doch reproduzierbar. Und wenn dir die Terminals ausgehen, schau dir mal screen an. ;-)
Also wäre interessant, was da anders ist.
Ich werfe da mal eine Idee in den Raum: die Prozesse werden in einer etwas anderer Reihenfolge beendet, und je nach dem wie viele und welche Prozesse laufen, wird ein Prozess beendet, ein anderer braucht aber noch was von dem. Irgendwie so.
möglich. Das ist aber schwer zu fassen.
ACK!
Ok, jetzt zerpflückt mal schön meine Idee. ;-)
*rupf*
Dich meinte ich jetzt weniger. Vielleicht weiß jemand, ob und falls ja, was da unterschiedlich abläuft.
Ich werde nepomuk updaten, da gibt es eine neuer Version und mal das Workaround des angegebenen Bugs anwenden.
Mal sehen, ob das Problem so verschwindet wie es kam, nämlich von jetzt auf nachher.
Wunschtraum? ;-) flo -- Wer immer nur wartet und wartet, der weiss eines Tages gar nicht mehr worauf er wartet. [WoKo in dag°] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
n'abend, Florian Gross schrieb:
ARGH! Google mal nach "mtrr allocation failed" (evtl noch (-22) mit reinnehmen). Nach (sehr) kurzem googeln meinerseits würde das eher auf Probleme mit dem Treiber der GraKa hindeuten.
Habe jetzt noch nicht gegurgelt. Ich habe zur Zeit leider nur sehr wenig Gelegenheit bzw. Zeit mich da reinzuhängen. Mehr als vielleicht eine viertel Stunde oder eine halbe pro Tag ist im Moment nicht drin. Die GraKa hatte ich von Anfang an im Verdacht, denn der shutdown bleibt ja gerade dann hängen, wenn die GraKa umschaltet. Vielleicht ist es aber auch andersrum, dass nämllich die Kiste einen Fehler produziert, der sich durch das Hängenbleiben und ein Um- bzw. Ausschalten der Grafikmodi äußert.
Probiere mal aus, ob es einen Unterschied bedeutet, wenn du a. sehr viele Prozesse (vor allem auch große, ressourcenfresende) b. sehr wenige Prozesse laufen hast.
Vielleicht ist das Problem doch reproduzierbar.
Und wenn dir die Terminals ausgehen, schau dir mal screen an. ;-)
Wie schon erwähnt, habe ich zur Zeit kaum Gelegenheit, mich systematisch auf Fehlersuche zu begeben. Ich spiele abends mit Sohnemann via wine ein kleines Hüpf und Sprungspiel. Dieses schaltet in den Vollbildmodus und nach Ende wieder zurück. Beim Zurückschaltet merkt man, dass es nicht einfach blubb macht, sondern dass da mehrere Stufen durchlaufen werden, die sich deutlich voneinander unterscheiden. Bei anderen Programmen ist mir das so noch nicht bewusst aufgefallen. Kann sein, dass das Programm hier was durcheinander wirft. Diese Phasen sind 1) ein Knack im Monitor (alte Elektronenkanone) und die Auflösung von 800x600 geht auf 1600x1200, gleichzeitig erscheint wieder KDE. Die Taskleiste und der Rest bleibt aber noch deutlich 1-2 Sekunden bei 800x600. 2) Das Hintergrundbild im kleinen KDE ist ein weiß- graues Karomuster 3) Dann flackert es und KDE geht auf 1600x1200, Hintergrund OK. 4) kurzes Dorschenanner, vielleicht ein kurzes weg und wieder da. 5) alles wieder in 1600x1200. fertig.
Ok, jetzt zerpflückt mal schön meine Idee. ;-)
*rupf*
Dich meinte ich jetzt weniger.
Vielleicht weiß jemand, ob und falls ja, was da unterschiedlich abläuft.
Im Falle von shutdown, also dem Drücken des "Runterfahren" Knopps im KDE-Menu wird KDE ja korrekt beendet und im Falle von init 0 einfach abgeschossen. Das ist schon mal ein Unterschied. Daraus würde ich aber eben eher das Gegenteil ableiten , nämlich, dass ein init 0 hängen bleibt (KDE nicht korrekt beendet) und beim normalen Runterfahren alles glatt geht. Für ein systematisches Durchspielen der Varianten prompt@Kiste>shutdown -h now prompt@Kiste>init 0 und dem Drücken des "Runterfahren"-Buttons hat's bisher noch nicht gereicht.
Ich werde nepomuk updaten, da gibt es eine neuer Version und mal das Workaround des angegebenen Bugs anwenden.
Mal sehen, ob das Problem so verschwindet wie es kam, nämlich von jetzt auf nachher.
Wunschtraum? ;-)
Ostern steht vor der Tür! ;-) Joachim -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (2)
-
Florian Gross
-
Joachim Hussong