Fatal Errors nach Bootsplash bei Leap

josef-wien · 19 Juni 2016

Eine mögliche Ursache (so nebenbei frage ich mich seit langer Zeit, warum manche [oder viele?] Distributionen das Thema Microcode hauptsächlich ignorieren) für die beiden Fehlermeldungen haben wir ausgeschaltet, wenden wir uns der nächsten zu. Definiere das Repo http://download.opensuse.org/repositories/Kernel:/stable/standard/ und installiere den aktuellen Kernel 4.6.

Der nächste Schritt wird dann die Analyse der Log-Ausgaben des Absturzes sein.

bayernherz · 19 Juni 2016

hallo community,

josef-wien hat geschrieben:
wenden wir uns der nächsten zu. Definiere das Repo http://download.opensuse.org/repositori ... /standard/ und installiere den aktuellen Kernel 4.6.

Bislang habe ich noch keinen Systemabsturz wieder erzeugt, obwohl die Fehlermeldung noch besteht.
Ich möchte es auch noch ein bischen beobachten, bevor wir den nächsten Schritt angehen.
Ich melde mich dann wieder.

viele grüsse aus dem abendlichen Oberbayern
vom bayernherz :thumbs:

bayernherz · 25 Juni 2016

hallo community,
jetzt habe ein bischen mit Leap bearbeitet.
Bildbearbeitung, Viedeobearbeitung, Netzwerk NFS NAS, Ruhezustand, Tiefschlaf.
Bislang keine weiteren Abstürze.

Die vorher genannte Fehlermeldung ist beim Starten nach wie vor vorhanden.
Gebootet wird der PC ohne UEFI.
Ich bin am überlegen ob es ratsam ist ein BIOS-Update durchzuführen, denn da bin ich einige Versionen zurück
u. ggf. wenn notwendig danach einen Kernel update durchzuführen.

Würde mich über einen Rat von Euch sehr freuen.

ps:

viele grüsse aus dem hochsomerlichen Oberbayern
vom bayernherz :thumbs:

josef-wien · 25 Juni 2016

Wenn es bei der "Absturzlosigkeit" bleibt, hat die Korrektur der Programmierfehler im Prozessor das Problem behoben. Ob ein neues BIOS oder ein neuer Kernel die beiden Fehlermeldungen ins Nirwana verschwinden lassen, kannst Du nur mittels Versuch herausfinden, negative Auswirkungen haben sie offenbar nicht.

bayernherz · 25 Juni 2016

hallo community,

josef-wien hat geschrieben
Wenn es bei der "Absturzlosigkeit" bleibt, hat die Korrektur der Programmierfehler im Prozessor das Problem behoben. Ob ein neues BIOS oder ein neuer Kernel die beiden Fehlermeldungen ins Nirwana verschwinden lassen, kannst Du nur mittels Versuch herausfinden, negative Auswirkungen haben sie offenbar nicht.

ehrlich gesagt, dann würde ich lieber erst noch mal abwarten und beobachten.
Wie kann ich verhindern, das neue Upgrades mir den älteren Microcode wieder überschreiben ? :???:

viele grüsse aus dem sonnigen Oberbayern
vom bayernherz :thumbs:

Sauerland · 25 Juni 2016

Wie kann ich verhindern, das neue Upgrades mir den älteren Microcode wieder überschreiben ?

Wenn es dieselbe Version wie die von mir erstellte im Update Repo geben sollte, kannst du diese ruhig installieren.

Ansonsten:
Finger weg von

Code:

zypper dup

bayernherz · 25 Juni 2016

Sauerland hat geschrieben:

Wenn es dieselbe Version wie die von mir erstellte im Update Repo geben sollte, kannst du diese ruhig installieren.

Code:

zypper lr -d
# | Alias                               | Name                                                    | Enabled | GPG Check | Refresh | Priority | Type   | URI                                                                          | Service
--+-------------------------------------+---------------------------------------------------------+---------+-----------+---------+----------+--------+------------------------------------------------------------------------------+--------
1 | download.opensuse.org-non-oss       | Haupt-Repository (NON-OSS)                              | Yes     | (r ) Yes  | Yes     |   99     | yast2  | http://download.opensuse.org/distribution/leap/42.1/repo/non-oss/            |        
2 | download.opensuse.org-non-oss_1     | Aktualisierungs-Repository (Nicht-Open-Source-Software) | Yes     | (r ) Yes  | Yes     |   90     | rpm-md | http://download.opensuse.org/update/leap/42.1/non-oss/                       |        
3 | download.opensuse.org-oss           | Haupt-Repository (OSS)                                  | Yes     | (r ) Yes  | Yes     |   90     | yast2  | http://download.opensuse.org/distribution/leap/42.1/repo/oss/                |        
4 | download.opensuse.org-oss_1         | Hauptaktualisierungs-Repository                         | Yes     | (r ) Yes  | Yes     |   90     | rpm-md | http://download.opensuse.org/update/leap/42.1/oss                            |        
5 | dvd                                 | dvd                                                     | Yes     | (r ) Yes  | Yes     |   60     | rpm-md | http://opensuse-guide.org/repo/openSUSE_Leap_42.1/                           |        
6 | http-download.opensuse.org-f7c9816b | home:luckyb69                                           | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/home:/luckyb69/openSUSE_Leap_42.1/ |        
7 | packman                             | packman                                                 | Yes     | (r ) Yes  | Yes     |   60     | rpm-md | http://packman.inode.at/suse/openSUSE_Leap_42.1/                             |

d.h.

Code:

zypper --update

ist erlaubt.
Und was ist, wenn wegen Repo Austausch oder Ersatz doch mal

Code:

zypper dup

notwendig ist ? :-?
viel grüsse aus dem nachtaglichen Oberbayern
vom bayernherz :thumbs:

josef-wien · 25 Juni 2016

bayernherz schrieb:
wenn ... zypper dup notwendig ist

Dann wird selbstverständlich auf die offizielle Version umgestellt, da ich das Repo von Sauerland nicht in Deiner Liste sehe.

bayernherz · 25 Juni 2016

hallo community,

josef-wien hat geschrieben:
Dann wird selbstverständlich auf die offizielle Version umgestellt, da ich das Repo von Sauerland nicht in Deiner Liste sehe.

Ist das die offizielle Liste ? :???:

josef-wien hat geschrieben:
Definiere das Repo http://download.opensuse.org/repositori ... /standard/ und installiere den aktuellen Kernel 4.6.

viele grüsse aus dem abendlichen Oberbayern
vom bayernherz :thumbs:

Sauerland · 25 Juni 2016

Nö, das ist zur zeit die offizielle Version für Leap:
http://download.opensuse.org/distribution/leap/42.1/repo/oss/suse/x86_64/ucode-intel-20150121-3.3.x86_64.rpm

Wenn es eine aktuelle Version geben würde, würde diese ins OSS-Update-Repo wandern........

bayernherz · 27 Juni 2016

hallo community,

Sauerland schrieb:
Wenn es eine aktuelle Version geben würde, würde diese ins OSS-Update-Repo wandern........

d.h. dauerhaft auf

Code:

zypper dup

verzichten, mit allen vor und Nachteilen oder Kernelupdate.
Was ich benötige, ist ein System mit dem ich verlässlich arbeiten kann u. nicht ggf. durch Systemabstürze meine Daten vernichte. :erschreckt:

Da ich das ja nicht beurteilen kann, komme ich zu Euch Spezialisten, die das können.
Ihr wisst ja:
Ein Spezialist ist ein Mensch, der von immer weniger immer mehr weiss,
bis er zu Schluss von nichts alles weiss.

Wozu würdet Ihr mir mit der Fehlermeldung:

Code:

dmesg |grep ERROR
[    1.785778] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A
[    1.785790] [drm:cpt_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun

raten.
Kernelupdate oder BIOS-Update oder beides ? :???:
und in welcher Reihenfolge ?

viele grüsse aus dem nachmittaglichen Oberbayern
vom bayernherz :thumbs:

josef-wien · 27 Juni 2016

Solange Du mir nicht durch entsprechende Log-Dateien das Gegenteil nachweisen kannst, behaupte ich nach wie vor, daß die beiden Fehlermeldungen des Direct Rendering Manager nichts mit Deinen (früheren) Abstürzen zu tun haben.

bayernherz schrieb:
Wozu würdet Ihr mir ... raten.

1. Nimm das Repo von Sauerland mit hoher Priorität in Deine Repo-Liste auf, oder sperre das Paket.
2. Schau von Zeit zu Zeit, ob es im Update-Repo eine aktuellere Version gibt.
3. Siehe meinen ersten Beitrag vom 25. Juni 2016.

P. S. Ganz allgemein und unabhängig vom vorliegenden Fall sollte man vor einem "zypper dup ohne Einschränkungen" immer zuerst nachdenken.

bayernherz · 27 Juni 2016

hallo community,
ok

ps: , ich spiele mit.

josef-wien hat geschrieben:
1. Nimm das Repo von Sauerland mit hoher Priorität in Deine Repo-Liste auf, oder sperre das Paket.

poste mir bitte noch mal den Repo-Link der hinzugefügt werden sollte, ich kann ihn nicht mehr finden.

ps:
oder welches Packet sollte ich sperren ? :irre:

josef-wien hat geschrieben:
2. Schau von Zeit zu Zeit, ob es im Update-Repo eine aktuellere Version gibt.

Wie sehe ich, ob das Update-Repo eine neue Version hat ?
Was sollte ich tun, wenn es eine neue Version hat. ?

josef-wien hat geschrieben:
3. Siehe meinen ersten Beitrag vom 25. Juni 2016

Beitrag vom 25. Juni 2016
Wenn es bei der "Absturzlosigkeit" bleibt, hat die Korrektur der Programmierfehler im Prozessor
das Problem behoben. Ob ein neues BIOS oder ein neuer Kernel die beiden Fehlermeldungen ins Nirwana verschwinden lassen, kannst Du nur mittels Versuch herausfinden, negative Auswirkungen haben sie offenbar nicht.

Momentan keine Abstürze ! :wink:

Die Repo Theorie ist für mich immer noch schwarze Magie, und schon gar bei der Varantenvielzahl :-x

viele grüsse aus dem abendliche Oberbayern
vom bayernherz :thumbs:

Sauerland · 27 Juni 2016

poste mir bitte noch mal den Repo-Link der hinzugefügt werden sollte, ich kann ihn nicht mehr finden.

Wie man aus einer URL den Link zum Repo herausbekommt?

Ich hab es mal gebaut:
http://download.opensuse.org/repositories/home:/Sauerland/openSUSE_Leap_42.1/x86_64/ucode-intel-20151106-16.1.x86_64.rpm

Das wäre der Link dann zum Repo:

Code:

http://download.opensuse.org/repositories/home:/Sauerland/openSUSE_Leap_42.1/

josef-wien · 27 Juni 2016

bayernherz schrieb:
welches Packet sollte ich sperren ?

Mann, oh Mann, wovon reden wir denn die ganze Zeit: Das Paket aus dem Repo von Sauerland.

bayernherz schrieb:
Wie sehe ich, ob das Update-Repo eine neue Version hat ?

Wenn die Erinnerung an meine openSUSE-Zeit nicht trügt:

Code:

zypper se -s ucode-intel

bayernherz schrieb:
Was sollte ich tun, wenn es eine neue Version hat. ?

Installieren, und das Repo von Sauerland wieder entfernen.

bayernherz · 28 Juni 2016

hallo community,
jetzt ist Leap wieder beim herunterfahren abgestürzt. :igitt:

Das System ist mit Textbildschirm auf der Kommandozeile stehengeblieben.
Keine Reaktion auf Kommandos.
Abschalten war nur noch per Power off möglich.

Ich würde mich freuen, wenn Du mir die Komandos zur Diagnose aus dem journalctl posten würdest.

viele grüsse aus dem morgndlichen Oberbayern
vom bayernerz :thumbs:

bayernherz · 29 Juni 2016

hallo community,
habe mit

Code:

journalctl --system --since=2016-06-25 --until=2016-06-29 >> /home/bayernherz/journal.txt

eine Diagnose durchgeführt.
Nachfolgend die Auswertung vom Absturtag 27.06.2016, da die ganze journal-Datei zu gross ist

Code:

grep Warning journal-27062016.txt
Jun 27 12:56:37 Tux-sen kernel: ACPI Warning: SystemIO range 0x000000000000F040-0x000000000000F05F conflicts with OpRegion 0x000000000000F040-0x000000000000F04F (\_SB_.PCI0.SBUS.SMBI) (20150410/utaddress-254)
Jun 27 12:56:37 Tux-sen kernel: ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\PMIO) (20150410/utaddress-254)
Jun 27 12:56:37 Tux-sen kernel: ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20150410/utaddress-254)
Jun 27 12:56:37 Tux-sen kernel: ACPI Warning: SystemIO range 0x0000000000000540-0x000000000000054F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB_.PCI0.LPCB.GPBX) (20150410/utaddress-254)
Jun 27 12:56:37 Tux-sen kernel: ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20150410/utaddress-254)
Jun 27 12:56:37 Tux-sen kernel: ACPI Warning: SystemIO range 0x0000000000000530-0x000000000000053F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB_.PCI0.LPCB.GPBX) (20150410/utaddress-254)
Jun 27 12:56:37 Tux-sen kernel: ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GPIO) (20150410/utaddress-254)
Jun 27 12:56:37 Tux-sen kernel: ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x000000000000057F (\_SB_.PCI0.LPCB.GPBX) (20150410/utaddress-254)

Code:

grep Error journal-27062016.txt
Jun 27 12:56:36 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 12:56:36 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT0._GTF] (Node ffff88040f4c6c98), AE_NOT_FOUND (20150410/psparse-536)
Jun 27 12:56:36 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 12:56:36 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88040f4c6ba8), AE_NOT_FOUND (20150410/psparse-536)
Jun 27 12:56:36 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 12:56:36 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT0._GTF] (Node ffff88040f4c6c98), AE_NOT_FOUND (20150410/psparse-536)
Jun 27 12:56:36 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 12:56:36 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88040f4c6ba8), AE_NOT_FOUND (20150410/psparse-536)
Jun 27 18:00:40 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 18:00:40 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT0._GTF] (Node ffff88040f4c6c98), AE_NOT_FOUND (20150410/psparse-536)
Jun 27 18:00:40 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 18:00:40 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT0._GTF] (Node ffff88040f4c6c98), AE_NOT_FOUND (20150410/psparse-536)
Jun 27 18:00:40 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 18:00:40 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88040f4c6ba8), AE_NOT_FOUND (20150410/psparse-536)
Jun 27 18:00:40 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 18:00:40 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88040f4c6ba8), AE_NOT_FOUND (20150410/psparse-536)
Jun 27 19:22:14 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 19:22:14 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88040f4c6ba8), AE_NOT_FOUND (20150410/psparse-536)
Jun 27 19:22:14 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 19:22:14 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT2._GTF] (Node ffff88040f4c6ba8), AE_NOT_FOUND (20150410/psparse-536)
Jun 27 19:22:14 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 19:22:14 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT0._GTF] (Node ffff88040f4c6c98), AE_NOT_FOUND (20150410/psparse-536)
Jun 27 19:22:14 Tux-sen kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
Jun 27 19:22:14 Tux-sen kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT0._GTF] (Node ffff88040f4c6c98), AE_NOT_FOUND (20150410/psparse-536)

Code:

grep ignoring journal-27062016.txt
Jun 27 12:56:37 Tux-sen systemd-udevd[206]: Network interface NamePolicy= disabled on kernel commandline, ignoring.
Jun 27 12:56:37 Tux-sen systemd-udevd[206]: Network interface NamePolicy= disabled on kernel commandline, ignoring.
Jun 27 12:56:37 Tux-sen systemd-udevd[424]: Network interface NamePolicy= disabled on kernel commandline, ignoring.

Code:

grep ERROR journal-27062016.txt
Jun 27 12:56:37 Tux-sen kernel: [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A
Jun 27 12:56:37 Tux-sen kernel: [drm:cpt_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun

viele grüsse aus dem morgendlichen Oberbayern
vom bayernherz :thumbs:

josef-wien · 29 Juni 2016

Nur Du kennst den Zeitpunkt des Absturzes, und nur diese Meldungen sind wichtig (am besten ungefiltert). Das Sichern von Xorg.0.log (vor dem nächsten Start) oder zumindest Xorg.0.log.old (nach dem nächsten Start, sofern es sich noch um die umbenannte Datei vom Absturz handelt) hast Du vermutlich versäumt. War https://de.wikipedia.org/wiki/Magische_S-Abf-Taste nicht erfolgreich? Im übrigen weiß ich nicht, wie ausführlich systemd protokolliert und ob eventuelle Absturzmeldungen noch auf die Platte geschrieben wurden.

P. S. Das Fehlerbild "Absturz beim Herunterfahren" scheint neu zu sein.

bayernherz · 30 Juni 2016

hallo community,

josef-wien hat geschrieben:
P. S. Das Fehlerbild "Absturz beim Herunterfahren" scheint neu zu sein.

Noch einen kleinen Nachtrag dazu, damit wir keinem Fantom nachjagen. :-|
Folgende Vorgeschichte haben hinterher beim Herunterfahren zum Einfrieren im Textblidschirm geführt.
Im Dateimanager Dolphin war ein Verzeichnis vom NAS-Server, der mittels NFS und autofs angekoppelt ist, geöffnet.
Mittels Root-Konsole wurde dann von mir mittels

Code:

umount /net/nas

der NAS abehängt, weil ich den NAS abschalten wollte, da er nicht mehr benötigt wurde.
Dolphin wurde danach von mir geschlossen und wieder geöffnet und für weitere Zwecke benutzt.
Es gab kein Problem mit dem Dateimanager !
Ob ich danach noch mal im Ruhezustand war, kann ich jetzt nicht mehr mit Sicherhiet sagen.
Diese Betriebsart wird sehr häufig von mir benutzt. :wink:

Beim späteren herunterfahren dann der Absturz. :igitt:

Soviel noch zu der Vorgeschichte.

josef-wien hat geschrieben:
Nur Du kennst den Zeitpunkt des Absturzes, und nur diese Meldungen sind wichtig (am besten ungefiltert). Das Sichern von Xorg.0.log (vor dem nächsten Start) oder zumindest Xorg.0.log.old (nach dem nächsten Start, sofern es sich noch um die umbenannte Datei vom Absturz handelt) hast Du vermutlich versäumt.

Ich habe Xorg.0.log.old und auch das journal vom Absturztab ungefiltert.
Wo soll ich diese Dateien speichern.
Bitte poste mir nochmal den Link, wenn es Sinn macht das Absturzsyndrom weiter zu verfolgen.

josef-wien hat geschrieben:
War https://de.wikipedia.org/wiki/Magische_S-Abf-Taste nicht erfolgreich?

Nicht mehr dran gedacht.

viele grüsse aus dem regengeplagtem Oberbayern
vom bayernherz :thumbs:

bayernherz · 2 Juli 2016

hallo community,

bayernherz hat geschrieben:
Ich habe Xorg.0.log.old und auch das journal vom Absturztag ungefiltert.

Wo kann ich diese Dateien hinterlegen ?
Dann könnten wir das Problem doch mal analysieren. :wink:

viele grüsse aus dem morgendlichen Oberbayern
vom bayernherz :thumbs: