[gelöst] Merkwürdige Pause beim Systemstart

[Fijoldar]

Hallo,

ich hoffe ihr könnt mir bei folgendem Problem etwas weiter helfen. Seit einigen Tagen beobachte ich, dass der Systemstart beunruhigend lange dauert. Ich habe das System auf einer SSD und normalerweise bootet es innerhalb weniger Sekunden. Aber seit kurzem hängt der Start etwas. Das System ist aber ansonsten voll funktionsfähig. Ich vermute, da hängt dann auch mit zusammen, dass das Herunterfahren manchmal nicht klappt, da bleibt er auch oft hängen und es tut sich gar nichts mehr. Ich kann leider nicht genau sagen, wann es zum ersten Mal aufgetreten ist. Aber ich vermute, seit ich keine Initramfs mehr nutze und alle nötigen Treiber in den Kernel kompiliert habe. Sicher bin ich mir da aber nicht. Verstehe auch nicht, warum das zu solchen Problem führen kann.

Als Init System kommt systemd (in der akutellen Version 208-r2) zum Einsatz. Kernel ist 3.10.21-gentoo.

Hier mal die Ausgabe von "dmesg", wo man sehr schön sieht, dass zwischen der 5. und 24. Sekunde eine sehr lange Pause ist. Auffällig sind auch noch die kryptischen Call Trace, die ich nicht so wirklich zuordnen kann. Der eine scheint vom Nivida Treiber zu kommen(?).

[Fijoldar]

Update

Ich habe mir mal einen neuen Kernel gebaut (3.11.10-gentoo). Erster Start hat geklappt. Sauber läuft es aber immer noch nicht. Hier mal die neue Ausgabe von dmesg. Zumal ich jetzt den neusten Nvidia Treiber 331.20 verwenden muss und damit der Akonadi Server nicht mehr läuft

Hat einer vielleicht eine Idee, was diese Fehlermeldung zu bedeuten hat? Ich kürze die Ausgabe mal etwas (hoffentlich nicht zuviel).

[py-ro]

Nvidia ist momentan beyond broken, nimm entweder nen alte Version oder lebe damit.

[Fijoldar]

Das mit dem Akonadi Server ist auch erstmal nicht so wichtig. Gerade funktioniert er unter 331.20.

Vielmehr bekomme ich das mit dem Systemstart nicht hin. Eben hat er sage und schreibe 10 Minuten gebraucht. Verdamte sch... 10 Minuten!!!! Mal geht es in 7 Sekunden, dann braucht er mal knapp eine Minute, dann geht's wieder in 7 Sekunden. Absolut willkürlich. Herunterfahren tut er schon gar nicht mehr sauber. Bleibt einfach irgendwo hängen ohne jegliche Fehlermeldung.

Ich baue mir jetzt mal einen stable Kernel 3.10.17 mit alter Konfig. Hat das so einen gewaltigen Unterscheid ob ich Treiber als Module oder fest integriert in den Kernel baue? Was anderes habe ich in den letzten Wochen nicht geändert. Nur USB und SATA Treiber statt {M} als {*} markiert. Mal sehen, ob es was ändert. So langsam habe ich nämlich meine USB Geräte in Verdacht. Ab und an passiert es nämlich mal, dass mein WLAN USB Stick nach dem Start nicht funktionieren will. Dann steck ich ihn aus und wieder ein. Dann funktioniert er wie gewohnt.

[py-ro]

Guck dir doch deine selber geposteten Stack Traces an, das liegt am Nvidia Modul, das ist alles.

[Fijoldar]

Danke.

Aber meinst du wirklich, der Nvidia Treiber ist da alleine dran schuld? Da scheint mir doch noch mehr kaputt zu sein. Da sind eine ganze Menge an Strack Traces zu erkennen und nur der eine lässt sich auf den Nvidia Treiber zurück führen. Wenn es wirklich nur der Nvidia Treiber wäre, müsste doch da was bekannt sein, oder nicht? Ich meine irgend ein Bug Report oder ähnliches. Bzw. kann ich nicht erklären, warum das dann so schwer reproduzierbar ist. Mal geht's. mal geht's nicht.

Welche Version läuft denn? Gerade scheint da ja so gut wie alles stable zu sein, aber keine scheint einfwandfrei zu funktionieren. Wie soll man denn da die richtige Version finden.

[Fijoldar]

Danke py-ro, du hattest Recht. Manchmal sieht man einfach den Wald vor lauter Bäumen nicht . Die Probleme beim Start treten immer zusammen mit Problemen des Nvidia Treibers auf. Die anderen Stack Traces treten zwar immer noch auf, aber sie sind für die Probleme beim Start nicht verantwortlich. Bin jetzt auf Kernel 3.10.17-gentoo mit Nvidia-Treiber 319.60. Irgendwie scheint da Gentoo mehr Probleme mit Nivida zu haben als andere Distributionen. Habe hier zu Testzwecken noch ein aktuelles Arch Linux mit aktuellem Nvida Treiber. Da gibt es solche Probleme nicht. Schon komisch... Daher hin ich auch zunächst nicht darauf gekommen, dass es der Nvidia Treiber sein könnte.

[Fijoldar]

Jetzt muss ich nur noch eine Kombination aus Kernel + Treiber zu finden, die zumindest für einen reibungslosen Start sorgt. 3.10.17-gentoo + Nivida Treiber 319.60 sorgt spätestens nach einen Neustart ebenfalls für Probleme. Gibt es hierzu Empfehlungen? Was funktioniert denn eigentlich noch?

Ich gehe mal zurück auf 3.4.74.

[Yamakuzure]

Jaja, immer gleich alles auf nvidia, aber schau mal genau hin:

[Fijoldar]

Danke für deine Hilfe, Yamakuzure!

Bzg. nvidia-smi: Wie schalte ich das denn aus? Ich habe das das nicht bewusst aktiviert und hatte bis jetzt ehrlich gesagt auch keine Ahnung was das ist. Vielleicht ist das ja wirklich der springende Punkt und würde die Probleme erklären.
--------------
Bzgl. GPL. Was genau sagt mir das? Mir ist bewusst, dass der Treiber nicht unter GPL steht. Aber wo ist da das Problem? Bzw. was muss man da tun?
--------------
Bzgl. cfg80211. Der lief monatelang ohne Probleme. Geändert habe ich da auch nichts. Könnte natürlich sein, dass da bei einem Kernel Upgrade irgendwas schief gelaufen ist. Wenn man eine alte Config übernimmt, kann da wohl manchmal einiges kaputt gehen. Der Kernel ist so kompiliert:

[Fijoldar]

Den Stack Trace, den cfg80211 verursachte, konnte ich beheben. Ich habe den Kernel ohne CFG80211_INTERNAL_REGDB gebaut. Danach war das Problem weg. Das war aber nicht das eigentliche Problem für die Startschwierigkeiten. Bleibt noch die Sache mit dem Nvidia Modul. Ist da das Problem eher beim Kernel oder beim Nvidia Treiber zu suchen?

[sprittwicht]

Der aktuelle Nvidia ist für die Tonne.
Kleine Liste der lustigen Fehler, die er bei mir verursacht hat: https://forums.gentoo.org/viewtopic-t-977432.html#7453680

Die Kombination gentoo-sources-3.10.17 + nvidia-drivers-325.15 läuft bei mir momentan einwandfrei...

[Fijoldar]

Der Nvidia Treiber scheint auch irgendwie den Start zu verzögern. Ich vermute nur, dass das Problem vielleicht in meinem Kernel zu suchen ist. Sonst müssten doch noch mehr solche Fehler bekommen. Vielleicht kann ja jemand mal kurz über meine Config schauen und sieht auf dem ersten Blick etwas, was fehlerhaft sein könnte.

http://cdn.2safe.com/495668033759/config-3.10.21.txt

[Fijoldar]

Ok, es scheint wirklich am Kernel gelegen zu haben. Ich habe in einem Backup eine recht alte Kernel Config gefunden und mit dieser den neuen Kernel gefüttert. Ergebnis: Keine Startschwierigkeiten mehr. Auch nach mehreren Neustarts läuft immer noch alles sauber. Welche Änderungen aber jetzt genau für die Probleme gesorgt haben weiß ich immer noch nicht. In Zukunft bin ich da aber etwas vorsichtiger .

[Yamakuzure]

Also das mit der GPL schrieb ich nur, da gerne Panik bei einer "Kernel Tainted"-nachricht aufkommt.

nvidia-smi wird unter openrc mit /etc/init.d/nvidia-smi gestartet. Wie gesagt, ich weiß nicht, wie das unter systemd geht, aber es müsste dort dann ja auch einen Service namens "nvidia-smi" geben.

Mit der Kernel-Config hat das nichts zu tun.

Bei mir läuft nvidia-drivers-331.20 mit 3.12.4 kernel, und ich habe keinerlei Verzögerungen. Starten/Stoppen von nvidia-smi funktioniert allerdings ohne jegliche Verzögerungen.

Was ich mir vorstellen könnte ist, dass der nvidia-Treiber wegen nvidia-smi bei dir schon zum Systemstart benötigt wird. Bei mir wird dieser erst beim Starten von X geladen.

...was vielleicht auch diverse andere Probleme, die hier im Forum genannt werden, erklären könnte... Probleme, die ich nie hatte.

[Fijoldar]

Ich habe meinen Kernel auch nie von Grund auf selbst konfiguriert. Ich bin irgendwann einmal von einer funktionierenden Config, die ich mir von einer anderen funktionierenden Live Distribution "geklaut" habe, ausgegangen und habe im Laufe der Zeit nach und nach Einstellungen angepasst. Sprich Treiber entfernt, als Modul markierte fest eingebaut etc. Daher sind da noch eine ganze Menge unnötiger Treiber vorhanden und viele Einstellungen nicht optimal.

Ich werde deine Tipps aber berücksichtigen und bei Gelegenheit mal einen genauen Blick auf die Kernel Config werfen. Danke vielmals für deine Hilfe!

Mit meiner alten Config habe ich jetzt zumindest wieder einen lauffähigen Kernel hinbekommen. Ich werde diesen mal mit der fehlerhaften vergleichen in der Hoffnung den Übeltäter irgendwann auszumachen. Es interessiert mich nämlich schon, was zu solchen gravierenden Problemen führen konnte.

[Fijoldar]

Das Problem ist nach einem Update wieder aufgetaucht .

Mit der Nvidia Treiber Version 325.15 hatte ich das Problem, dass ich nicht mehr auf eine andere virtuelle Konsole wechseln konnte, d.h STRG+ALT+{F1,...,F6} brachte mich nur zu einem schwarzen Bildschirm. Ich konnte aber problemlos auf tty7 zurück. Nach einem emerge --sync habe ich gesehen, dass Nvidia-drivers-325.15 entfernt wurde. Also Downgrade auf 319.76 durchgeführt. Ergebnis: Wieder Startprobleme und Fehlermeldungen. Da ist doch echt der Wurm drin.

Ich poste hier nochmal die genauen Fehlermeldungen, welche immer wieder auftauchen:

[Fijoldar]

Du hast einen interessanten Punkt angesprochen, Yamakuzure! Und zwar: Systemd!!!!! Bzgl. des Service nvidia-smi dachte ich mir, boote doch einfach mal mit dem alten openrc und siehe da: Keine Probleme! Bootet ganz normal durch. Es kann auch nur Zufall gewesen sein, aber die diese Richtung muss ich mal weiter schauen. Denn ein anschließendes Booten mit systemd hat wieder nicht geklappt. Teilweise fährt er gar nicht mehr hoch, sondern bleibt minutenlang beim Boot Vorgang hängen. Ich schaue mir das mal bei Arch Linux an. Evtl. haben die ja einen entsprechenden Service für nvidia-smi oder ich entdecke was anderes, was da beim Start passiert.

[Yamakuzure]

Es steht noch der Versuch offen, den Kernel mit "apci=ht noapic" zu starten. Wir haben hier einen Server, bei dem das ACPI irgendwie komisch ist, und ohne diese Boot-Parameter kommt es andauernd irgendwo zu diesen "RCU CPU stall"-Meldungen, und runterfahren geht garnicht.

Ich habe im Übrigen gerade gesehen, dass nvidia-smi direkt über udev gestartet wird.

In /lib/udev/rules.d/99-nvidia.rules wird /lib/udev/nvidia-udev.sh aufgerufen, und das startet direkt /opt/bin/nvidia-smi wenn das Modul geladen wird.
Vielleicht kannst du einmal ausprobieren dem Aufruf von nvidia-smi in dem Skript die Parameter "-pm 1" hinzuzufügen?

Allerdings verstehe ich immernoch nicht, warum das Modul bei dir überhaupt so früh geladen wird...
_________________
Edited 220,176 times by Yamakuzure

[Fijoldar]

Kurzes Zwischenergebnis:

Ich habe mal versucht mit dem Parameter "apci=ht noapic" zu starten. Das ändert leider nichts. Hätte mich ehrlich gesagt auch gewundert, weil der Rechner ja bisher immer ohne solche Paramter gestartet ist und bisher keine Probleme machte. Aber man weiß ja nie. Hat aber leider nicht geholfen.

Versuche mit openrc scheinen keine Probleme zu machen. Konnte jetzt 3 mal starten/beenden ohne Auffälligkeiten. Das würde meinen Verdacht erhärten, dass der Wurm irgendwo in Systemd ist. Allerdings frage ich mich dann, warum das Problem erst wieder nach einem Update vom Nvidia Treiber aufgetreten ist. Evtl. versuche ich mal ein Downgrade auf Systemd 204. Das lief, so weit ich weiß, ohne Probleme.

Ab und zu startet der Rechner auch mit System problemlos. Das scheint mir aber ziemlich willkürlich zu sein. Auf 5 fehlerhafte Versuche kommt 1 fehlerfreier Versuch. Bei einem solchen sieht die dmesg dann so aus: Ich sehe nur noch nicht, wo der Punkt ist, an dem es zu den Aussetzern kommt.

[uhai]

Dienste unter systemd startet man doch mit systemctl enable Dienst.service" soweit ich weiss...

Alle möglichen Dienste gibt Dir systemd --all (| grep nvidia wäre vermutlich gut).

Ausserdem siehst Du die gescheiterten Aufrufe mit systemctl --failed.

Ich habe neuerdings ebenfalls lange pausen mit schwarzem Bildschirm beim Start. Allerdings bstle ich gerade mit E17 herum, das könnte auch der Grund sein. Nvidia-Karte mit nvidia-Treiber habe ich hier auch. Hast Du mal nouveau probiert? Ist es damit besser?

Bei mir ist seit gestern automount weg. Funktioniert das bei Dir noch?

uhai

[Fijoldar]

Ich habe mir jetzt mal die Einträge von journalctl genauer angesehen. Aufgefallen sind mir da besonders diese Zeilen:

[uhai]

Ich habe KDE genutzt und bin aus Neugier zu enlightenment gewechselt. Dafür habe ich den login mit slim eingerichtet und kwin "abgeklemmt". Dann kam es zu mehreren Starts mit langen, schwarzen Pausen... Ein Wechsel der Konsole um am Prompt zu sehen, was läuft hat nicht funktioniert während der "Ruhepausen".

Gezielt analysiert habe ich das nicht. Ich habe die letzten Tage mit cups-Problemen und fehlenden Modulen von enlightenment zugebracht.

Meine Starts laufen zwischenzeitlich wieder normal.

Sorry, hilft Dir vermutlich nicht weiter, oder?

uhai

[Fijoldar]

Falls es bei dir nochmal auftreten solltest, könntest du vielleicht mal dmesg aufrufen und schauen ob da ähnliche Stack Traces auftreten? Wenn nicht, dann ist das wohl eine andere Geschichte. Trotzdem danke

[Yamakuzure]