PC stürzt mit "XIO: fatal IO errror 11" ab

[wuppi]

Nein, ich schalte derzeit ACPI nicht per Grub-Zeile aus. Das war auf dem ursprünglich von Jessie nach Stretch hochgezogenen System so, beim jetzigen Jessie und dem jetzigen zweiten Rechner mit einer neuen, frischen Stretch-Installation ist das nicht mehr der Fall.

Die Idee, den Status auf C1 direkt im Image festzuschreiben ist gut. Er verhindert ein mögliches Problem im BIOS.
Nur ist mir im Artikel nicht ganz klar geworden, wo ich das in Debian Stretch oder Jessie eintragen muss:

In /etc/default/grub

in der Zeile GRUB_CMDLINE_LINUX_DEFAULT
processor.max_cstate=1 intel_idle.max_cstate=0
anfügen und dann update-grub machen?

Zu den weiteren Erkenntnissen scheint nun klar zu sein, denn beide Rechner, sowohl der Jessie als auch der Stretch-Rechner laufen seit der Bios-Änderung ohne Probleme:

Das Problem ist gelöst durch das Setzen des BIOS-Eintrags Max-CPU State auf C1 (Von ursprünglich C7).

Da die Stretch Installation sehr gut funktioniert hat und auch der Bildschirm nicht mehr durch Tricks gehindert werden muss, sich auszuschalten, werde ich die
frische Stretch-Installation weiter entwickeln und die Jessie Installation nicht mehr auf Stretch updaten um evt. Altlasten loszuwerden.

@NAB: Ich würde mich natürlich freuen, wenn ich mich dazu weiter mit Dir austauschen könnte, aber das sollten wir evt. besser per Private Message als im Forum machen, was meinst Du?

[NAB]

Nein, ich schalte derzeit ACPI nicht per Grub-Zeile aus. Das war auf dem ursprünglich von Jessie nach Stretch hochgezogenen System so, beim jetzigen Jessie und dem jetzigen zweiten Rechner mit einer neuen, frischen Stretch-Installation ist das nicht mehr der Fall.

Da bin ich mir bei deinem Jessie nicht so sicher. Dem Threadverlauf nach ging ich auch davon aus, dass du das apm=off erst später nach dem Update auf Stretch eingefügt hast. Zu meiner Überraschung tauchte es in deinem letzten dmesg nach dem Einspielen deines Jessie-Backups aber auch auf. In Anbetracht deiner nächsten Frage drängt sich der Eindruck auf, dass du selber nicht mehr so genau weißt, was du alles verbastelt hast.

Prüfen kannst du das mit

Code: Alles auswählen

dmesg | grep -i command

Die Idee, den Status auf C1 direkt im Image festzuschreiben ist gut.

Ich bin mir ziemlich sicher, dass "C5" reicht. C1 bis C5 existieren seit über 10 Jahren, die sollten keine Probleme machen. C6 kam vor wenigen Jahren hinzu und sollte inzwischen "eigentlich" auch funktionieren. Vermutlich macht C7 den Ärger.

Zur Verdeutlichung: du betreibst da einen 6Watt-Prozessor in einem passiven Gehäuse. Meine Lötnadel hat 7 Watt und wird 350 Grad warm bei "passiver" Kühlung. Du möchtest so wenig Stromsparmechanismen ausschalten wie möglich. Die Monitore hängen "oben"? Da wo es schön warm ist?

In /etc/default/grub
in der Zeile GRUB_CMDLINE_LINUX_DEFAULT
processor.max_cstate=1 intel_idle.max_cstate=0
anfügen und dann update-grub machen?

Ja, der Vorgang ist genau richtig. (Wie hast du das vorher gemacht?).
Aber ich würd's erst mal mit processor.max_cstate=5 versuchen und das intel_idle.max_cstate ganz weglassen. Siehe oben.

Da die Stretch Installation sehr gut funktioniert hat und auch der Bildschirm nicht mehr durch Tricks gehindert werden muss, sich auszuschalten, werde ich die
frische Stretch-Installation weiter entwickeln und die Jessie Installation nicht mehr auf Stretch updaten um evt. Altlasten loszuwerden.

Nun mal nicht so schnell. Ich vermute, du bist auf Stretch immer noch ohne passende Firmware für deine Grafikkarte unterwegs. Nun geht's offensichtlich auch ohne, aber erst mit Firmware hast du volle Unterstützung für deine Hardware. Also schalte in der /etc/apt/sources.list mal "non-free" frei und installiere "firmware-linux-nonfree". Das sollte "firmware-misc-nonfree" und "intel-microcode" mit reinziehen. Und dann schalte das BIOS noch mal auf Werksvorgabe und guck mal, was passiert.

Ob er fehlende Firmware bemängelt kriegst du mit

Code: Alles auswählen

dmesg | grep irmware

heraus.

Ein komplettes Neuaufsetzen halte ich immer noch für überflüssig. Aber wenn die Arbeit überschaubar ist, mach ruhig. Nimm dafür doch einen dritten Rechner. Und mach dir eine Dokumentation in einer einfachen Textdatei - eingegebene Befehle und geänderte Dateien.

@NAB: Ich würde mich natürlich freuen, wenn ich mich dazu weiter mit Dir austauschen könnte, aber das sollten wir evt. besser per Private Message als im Forum machen, was meinst Du?

Du, der einzige Grund, warum ich hier kostenfreien Support für dein kommerzielles Problem mache ist, dass andere Leute auch was davon haben. Vielleicht will ja wer anders auch mal einen Gigabyte BACE mit Debian betreiben. Also entweder im Forum oder ich schick die ne Rechnung.

[wuppi]

Das mit der Dokumentation beim Aufsetzen des Systems hatte ich bereits für Jessie gemacht und aktualisiere es natürlich gerade für Stretch.

Der Aufwand für das Neuaufsetzen ist zwar unglücklich, aber ich habe mich jetzt dazu entschlossen und werde ihn gerne leisten, damit ich ein stabiles System habe.
Das Jessie System war bereits hard- und softwaremigriert von einer ZBOX und ich traue dem Braten nicht mehr in Bezug auf das Screensaving Thema.
Das Jessie-System lasse ich noch so lange "leben", wie ich das Stretch-System noch "testing" habe.

C-States werden vom BIOS in Version F5 nur C1, C6 und C7 angeboten.

@NAB, Ich wollte niemandem zu nahe treten, vor allem Dir nicht und bin natürlich dankbar für Deine und andere Unterstützungen.
Mit meinem Vorschlag, PMs auszutauschen wollte ich nur so wenig im Forum "nerven", wie es geht.

Mir scheint das ursprüngliche Thema eigentlich gelöst. Jetzt haben wir ja eher ein neues Thema mit dem Aufsetzen des Gigabyte BRACE.
Sollten wir da nicht einen neuen Thread aufsetzen? Wenn ja, wie?

Die Firmware-Sachen kann ich frühestens morgen NAchmittag machen, da ich Auswärts-Termine habe, evt. sogar noch später.

[wuppi]

@REVOD

Eine Lösung ab Stretch das System mit lxde direkt herunter fahren zu können, ohne weitere Bestätigungen wäre doch auch eine interessant Lösung

Das geht in Jessie und Stretch. Wie gesagt, ich erzeuge per PHP-Skript eine Dummy-Datei in /tmp namens "shutdown" und polle mit einem BASH-Script, welches ich per Systemd-Job periodisch aufrufe
nach dessen Existenz. Dann führe ich einfach ein Shutdown durch.

Damit kann der Rechner per Browser heruntergefahren oder rebootet werden.

http://<ip-des-Rechners>/shutdown
bzw.
http://<ip-des-Rechners>/reboot

Bei Interesse poste ich gerne die Lösung, dann aber evt unter einem anderen Thread.

[wuppi]

@NAB: Zur Info: Der BRACE wird auch nach mehreren Tagen Betrieb in C1 nur handwarm.

[NAB]

@NAB: Zur Info: Der BRACE wird auch nach mehreren Tagen Betrieb in C1 nur handwarm.

Joa ... mein Lötkolben ist in 10 cm Entfernung nicht mal mehr handwarm. Gibt

Code: Alles auswählen

cat /sys/class/thermal/thermal_zone*/temp

bei dir was aus?

C-States werden vom BIOS in Version F5 nur C1, C6 und C7 angeboten.

Ich würd C6 mal ne Chance geben. Sonst kannst du ihn mit processor.max_cstate auf 5 festnageln.

wollte ich nur so wenig im Forum "nerven", wie es geht.

Ob hier jemand nervt haben die Moderatoren zu entscheiden. Ich hab hier bisher keine Beschwerden gesehen. Das ist ein ganz normaler "Hilfe, meine Kiste stürzt zufällig ab"-Thread - die werden gerne mal etwas länger, während man im Nebel stochert.

Mir scheint das ursprüngliche Thema eigentlich gelöst. Jetzt haben wir ja eher ein neues Thema mit dem Aufsetzen des Gigabyte BRACE.

Wie du ja merkst ... ich bin mit C1 noch nicht so richtig glücklich. Außerdem frage ich mich, ob's mit "firmware-misc-nonfree" und "intel-microcode" nicht sogar noch besser wird ... oder gar schlimmer. Aber was für dich funktioniert musst letztendlich du wissen.

Heißen die Dinger nun eigentlich BACE oder BRACE? Ich find nur BACE. Ich bin ja schon froh, dass sie sie nicht mehr Brix nennen

und polle mit einem BASH-Script, welches ich per Systemd-Job periodisch aufrufe nach dessen Existenz.

Man könnte das Script auch als Dauerläufer gestalten, mit inotify, das spart das Polling:
https://superuser.com/questions/956311/ ... ectories-r
Und eigentlich sollte man es auch ganz ohne Script hinkriegen können, mit "systemd.path":
https://www.freedesktop.org/software/sy ... .path.html
Aber wenn's läuft ... wozu ändern?

[wuppi]

Nachdem ich nun in den vergangenen Tagen insbesondere die Non-Free-Treiber, speziell den Grafikkartentreiben i915 geladen habe, sehe ich wieder das Phänomen, dass der Bildschirm sich
nach einiger Zeit stromlosem Monitor abschaltet und sich heute auch einmal der PC wieder abgeschaltet hat.

Insofern habe ich den Verdacht, dass die C-States nicht der Weisheit letzter Schluß gewesen sein könnten und würde aktuell gerne wieder den Standard-Treiber von Stretch laufen lassen.

Gibt es dazu eine einfache, womöglich zunächst temporäre Lösung, um das zu erreichen?

[NAB]

Erklärbär: Was du da aus "non-free" installiert hast, ist kein neuer Treiber, sondern "Firmware", also Software, die in der Grafikkarte läuft (nicht auf dem Prozessor) und zusätzliche Funktionen bereitstellt (z.B. 3D Beschleunigung). Du benutzt nach wie vor den Grafiktreiber "i915", daran hat sich nichts geändert. (hoffe ich, sonst hast du was Komisches gemacht).

Du kannst jetzt einfach "firmware-linux-nonfree" und danach "firmware-misc-nonfree" wieder deinstallieren, und die Firmware ist wieder weg. (Ach so, "intel-microcode" könnte es auch noch sein).

Wenn dir das nicht "temporär" genug ist, kannst du auch mit

Code: Alles auswählen

dmesg | grep irmware

mal nachgucken, welche Firmware(s) der Kernel überhaupt lädt, und diese erst mal mit "mv" aus dem Weg schieben. Die Dateien liegen alle in /lib/firmware/ plus evtl. Unterverzeichnis.

Mich persönlich würd dieser Zustand ziemlich ankotzen (keine 3D- & Video-Beschleunigung) aber ich sehe nicht, wozu du bei deiner Anwendung diese Firmware brauchst. Bisher lief es auch ohne (Jessie kannte diese Firmware noch gar nicht). Wenn Stretch mit Firmware schlechter läuft als ohne, macht es keinen Sinn, darauf zu bestehen.

Wenn du danach noch nicht die Nase voll hast vom Experimentieren, gäbe es da noch eine neuere Firmware in den stretch-backports:
https://packages.debian.org/stretch-bac ... sc-nonfree
Leider fehlt da die Dateiliste, aber wenn du auf "Debian-Changelog" klickst, siehtst du, was sich geändert hat. Du müsstest eine "Broxton"-Grafik haben, da gibt es eine neuere Version.

[wuppi]

Ich finde die genaue Firmware der Graka nicht.

Code: Alles auswählen

# dmesg | grep irmware
[   11.146622] iwlwifi 0000:02:00.0: firmware: direct-loading firmware iwlwifi-3160-17.ucode
[   11.147347] iwlwifi 0000:02:00.0: loaded firmware version 17.352738.0 op_mode iwlmvm
[   13.163557] r8169 0000:03:00.0: firmware: direct-loading firmware rtl_nic/rtl8168h-2.fw

Ich hatte versucht, mit Bootparametern des Moduls i915 das Problem zu lösen:

http://nopaste.debianforum.de/40154

Gesetzt habe ich über grub

Code: Alles auswählen

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0 intel_idle.max_cstate=1 i915.disable_power_well=0 i915.enable_dc=0 i915.enable_execlists=0 i915.enable_rc6=0"

Das Setzen hat auch funktioniert, wie ich nach dem Reboot unter

Code: Alles auswählen

# ls /sys/module/i915/Parameters

festgestellt habe. Heute morgen war der Rechner noch an, aber das Ausschalten ist ja teilweise auch erst nach bis zu > 24 Stunden aufgetreten.
Allerdings hat der Treiber trotz meiner Grub-Einstellungen den Port des Monitors nach einiger Zeit ausgeschaltetem Monitor deaktiviert.
Wenn ich dann nach einiger Zeit den Monitor wieder einschalte, habe ich kein Bild mehr.

Die Pakete "firmware-linux-nonfree" und danach "firmware-misc-nonfree" möchte ich nicht so gerne deinstallieren, weil sie ja auch die WiFi und
LAN-Treiber enthalten.

Ich habe jetzt mal das Verzeichnis /lib/firmware/i915 woanders hin geschoben und rebootet.
Anscheinend ist jetzt zumindest das Problem, dass sich der Monitorport nach einiger Zeit, in der der Bildschirm stromlos ist, abschaltet, wieder weg.
Der Rechner läuft auch noch, aber das ist ja erst ein paar Stunden.

Jetzt stelle ich mir die Frage, wie ich das Modul i915 sauber langfristig deaktiveren kann, denn wahrscheinlich würde ein
apt-get update ja die i915 Treiber wieder neu laden, was ich wohl eher verhindern möchte.

Die Installation des neuen Treibers aus den Backports will ich mal als Plan B hinten anstellen.

[NAB]

Verdammt noch mal, verzeihung, ich hab dir Blödsinn erzählt. Intel hat die Skylake-Grafik (die eine Firmware braucht) erst mit "Apollo Lake" eingeführt:
https://www.heise.de/newsticker/meldung ... 11646.html
Dein N3150 gehört noch zur Vorgängergeneration "Braswell" und braucht gar keine Firmware.
Ich hab mich von den 3000er Nummern täuschen lassen.

Und du liegst falsch.

Die Firmware "rtl_nic/rtl8168h-2.fw" für deine Netzwerkkarte stammt aus dem Paket "firmware-realtek":
https://packages.debian.org/stretch/firmware-realtek
Und die Firmware "iwlwifi-3160-17.ucode" für deine Wlan-Karte stammt aus dem Paket "firmware-iwlwifi":
https://packages.debian.org/stretch/firmware-iwlwifi

Du hast also noch einige zusätzliche Pakete aus "non-free" installiert.

Wenn ich die Reihenfolge richtig verstanden habe, sah es so aus:
Mit nacktem Stretch ohne zusätzliche Pakete aus "non-free" lief er problemlos.
Sobald du zusätzliche Firmware-Pakete installiert hast, ging der Ärger wieder los.

Du verdächtigst den i915. An dem kann sich durch die Firmware-Pakete aber eigentlich nichts geändert haben, denn der verwendet gar keine Firmware. Du kannst die Pakete "firmware-linux-nonfree" und danach "firmware-misc-nonfree" einfach wieder entfernen, es sollte keinen Unterschied machen.

Ich weiß nicht, woran du sonst noch rumgebastelt hast, aber momentan würde ich "firmware-realtek" und "firmware-iwlwifi" verdächtigen. Die Idee ist nicht völlig abstrus ... es könnte sein, dass die Firmware den Karten tiefere Stromsparzustände beibringt und der Rechner dadurch überhaupt erst so tief einschläft, dass er nicht mehr aufwacht. (Wobei er das mit C1 eh nicht tun sollte, so ganz glücklich bin ich mit der Theorie also nicht)

Deine LAN-Karte läuft auch ohne "firmware-realtek". Brauchst du WLan? Falls nicht, können beide weg.

Ich denke, vorallem diese mysteriösen Abstürze müssen unbedingt vermieden werden. Den Monitorausgang kriegst du ja auch mit deinem Script in den Griff.

[wuppi]

Ja, ich habe die Pakete für den Realtec-Treiber und WIFI installiert und nein, ich benötige DERZEIT nicht wirklich WLAN.
Ich habe über das Wochenende den i915 Treiber im Kernel-Bootparameter deaktiviert:

Code: Alles auswählen

# vi /etc/default/grub

GRUB_CMDLINE_LINUX="modprobe.blacklist=i915"

# update-grub

Hinweis: Die komplette Zeile hat noch weitere Parameter und sieht insgesamt so aus, aber das sollte für das Problem egal sein.
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0 modprobe.blacklist=i915"

Damit ...
- ist der PC nicht runtergefahren/abgestürzt
- bleibt der Monitorport auch dann aktiv, wenn der Monitor längere Zeit aus ist.

[NAB]

Weißt du ... du benutzt seit der Stretch-Installation den i915-Treiber. Immer die gleiche Version, du hast daran nichts geändert. Firmware benutzt der auch nicht.
Und erst hast du berichtet, er stürzt nicht mehr ab, dann stürzte er wieder ab ... nun hast du i915 geblacklistet und er stürzt grad nicht mehr ab. Hmm?

Wenn's so läuft, wär das ja fein, aber ich befürchte, dein Absturzproblem ist einfach sehr zufällig.

Mit

Code: Alles auswählen

lspci -k | grep 915

kannst du übrigens nachgucken, ob der i915-Treiber jetzt wirklich nicht mehr läuft. (leere Antwort = läuft nicht)
Mit lspci -k kannst du dementsprechend gucken, welchen Treiber er stattdessen verwendet.

[wuppi]

Es wird für mich immer undurchschaubarer.
der Befehl liefert in der Tat ..

Code: Alles auswählen

# lspci -k | grep 915
        Kernel driver in use: i915
        Kernel modules: i915

Demnach wird der Treiber weiter genutzt. Aber es gibt nach dem Blacklisten auf jeden Fall die reproduzierbare Änderung, dass der Monitorport auch
dann an bleibt, wenn das System einige Stunden aus war. Das war vor dem Blacklisten nicht der Fall. Wie erklärt sich das?

Das Wort "Zufall" klingt in meinen Ohren bei EDV nicht beruhigend.

[NAB]

Du bist jetzt bei deinem Monitorport - ich bin bei deinen Abstürzen.

Das mit dem Blacklisten funktioniert nur so mittelprächtig. Es gilt nur für Kernel-Automatismen, wo der Kernel selber nach passenden Treibern sucht.

Du könntest danach jederzeit ein "modprobe i915" ausführen und den Treiber damit laden. Oder ein Programm macht das in deinem Auftrag.

Ich vermute, das Blacklisten funktioniert. Zuerst wird ein anderer Treiber geladen - vesa oder so. Später lädt evtl. dein X-Server dann den i915 Treiber. Eine grobe Erklärung wäre dann, dass der erste Treiber eine andere Grundkonfiguration der Grafik durchführt, so dass der Monitorport nicht einschläft, und der i915-Treiber diese Grundkonfiguration später übernimmt. Das habe ich mir gerade wild aus dem Ärmel geschüttelt, es mag auch anders sein. "dmesg" erzählt dir vielleicht genaueres.

Ich verstehe, dass dich "Absturz" und "Monitorport" gleichermaßen nerven, aber du solltest beide Probleme gründlich trennen. Mit dem Monitorport habe ich mich noch gar nicht beschäftigt. Du sagtest, den Monitorport kriegst du mit "xrandr" wieder aktiviert. Damit bist du auf der Ebene von X und somit auf der Ebene des X-Treibers, nicht mehr des i915-Treibers.

X verwendet einen eigenen Treiber (der auf dem i915 aufsetzt) und hat eine eigene Energieverwaltung. Ich würd's da erst mal mit einem "xset -dpms" versuchen, vielleicht reicht das schon, um dem Monitorport das abschalten abzugewöhnen. Mit "xset q" kannst du prüfen, ob deine Einstellung Bestand hat oder ob dir ein anderes Programm dazwischenfunkt.

Ansonsten würde ich erst mal gucken, welche Konfigurationsmöglichkeiten der X-Treiber so bietet. Das macht man in der "xorg.conf". Und um die Sache noch komplizierter zu machen, gibt es inzwischen zwei verschiedene X-Treiber für Intel-Grafik: "modeset" und "intel". Momentan benutzt du den "modeset"-Treiber.

Andererseits ... wenn's mit dem modprobe.blacklist=i915 zuverlässig funktioniert, ist die Lösung doch auch gut.

[wuppi]

... aus dem Punkt, dass der Monitorport sich auch bei längere Zeit abgeschaltetem Monitor nicht mehr völlig abschaltet, habe ich geschlossen, dass der i915-Treiber nicht mehr verwendet wird. Das scheint ja in der Tat irgendwie nun doch nicht der Fall zu sein.
Sagen wir mal so, aktuell scheine ich mit dem Blacklisten über den Kernelbootparameter eine stabile Situation hinzubekommen.
Jedenfalls erlebe ich derzeit (noch) keine Abstürze mehr.

Und wie Du schon sagst, @NAB, das ist das wirklich wesentliche.

Sollte sich das nochmals ändern (ich hoffe nicht), würde ich das Thema aufgreifen.

[NAB]

Was ist denn aus dem "C1" bzw. dem max_cstate=1 geworden? So wie du es beschreibst, ist modprobe.blacklist=i915 jetzt die einzige "absturzspezifische" Anpassung?

Hier:
viewtopic.php?f=2&t=168217&start=60#p1163422
warst du übrigens schon mal der Meinung, dass der Rechner stabil läuft, mit C1, bis du Firmware hinzugefügt hast.
So richtig logisch kommt mir das noch nicht vor. Ich weiß, dir auch nicht.

[wuppi]

Der C-Status wird weiterhin über das BIOS eingestellt.
Ich habe es im aktuellen Image nicht über den Boot-Parameter eingestellt.
Aber das der Default-C7-Status ein Problem darstellt, konnte ich vorgestern live erleben, als ich nach der BIOS-Aktualisierung eines weiteren PC und
Image aufspielerei miterleben konnte, dass der Rechner sich selbst herunterfuhr - wegen C7.

Und ja, ich war zu dem Zeitpunkt in der Tat der Meinung, dass das System stabil läuft und seit dem Boot-Parameter, der den i915 Treiber blacklistet,
scheint das auch wieder der Fall zu sein - in Verbindung mit dem C-Status.