Und als gäbe es nicht schon genug Probleme: System freeze!

[northfrisia]

Moin,

sorry, wenn ich schon wieder mit einem Problem ankomme. Dieses Problem gab es schon bei meinem verhunzten
System und ich hatte gehofft, es mit der Neuinstallation losgeworden zu sein.

OS: Gentoo Linux x86_64, desktop, multilib
CPU: AMD Ryzen 5 3600 (12) @ 4.21 GHz
GPU: NVIDIA GeForce RTX 2060 SUPER [Discrete]
Display (HP LP2475w): 1920x1200 @ 60 Hz in 26" [External]
Kernel: Linux 6.12.38-gentoo-dist mit original-Config
Openbox, X11, sddm

(beide Versionen verändern nichts am Problem)
x11-drivers/nvidia-drivers-570.169
x11-drivers/nvidia-drivers-570.172.08

Genauere Problembeschreibung:
Das System friert ohne ersichtlichen Grund ein: Der
Bildschirminhalt bleibt stehen (also kein "blank") und der
Rechner reagiert nicht mehr.
Die Prozesse scheinen aber weiterzulaufen: Ein Video, was
lief, als es mal wieder passierte, fror ein...der Ton lief aber weiter.
Leider hat logrotate das alte Xorg.log gelöscht.
Sobald ich wieder eines mit Fehler habe, wird es hier verlinkt
werden.
Das Problem scheint nicht ganz unbekannt und ziemlich alt zu sein.
Alle Referenzen, die ich finden konnte - wenn sie dann überhaupt eine
Lösung enthielten, war nicht auf meine Situation anwendbar.

Im log stand irgendetwas mit Push und DMA - Probleme...wenn ich mich
recht entsinne...

Das Ganze scheint auch irgendwie in Zusammenhang mit DPMS und dem screensaver-Timeout
zu stehen. Sicherheitshalbe habe ich mal
xset -dpms
xset s off
ins autostart.sh gesetzt...was aber bestimmt keine finale Lösung ist...

Hat jemand von Euch mit dem Problemfeld Erfahrung?

Cheers!

[haegar87]

Servus,

wenn du das Logfile postet, dann nicht nur das Xorg.log sondern auch den passenden Ausschnitt aus dem normalen System log. Wenn bspw. das NVIDIA Modul aussteigt, sollte sich die Fehlermeldung eher im syslog statt im Xorg.log finden.

Falls du einen zweiten Rechner (oder Smartphone mit der passenden App) hast kannst du nach dem "hängen" noch versuchen per SSH (falls aktiviert) auf den Rechner zuzugreifen. Dann kann man den Fehlerzustand in "Echtzeit" sehen.

[northfrisia]

Servus,

wenn du das Logfile postet, dann nicht nur das Xorg.log sondern auch den passenden Ausschnitt aus dem normalen System log. Wenn bspw. das NVIDIA Modul aussteigt, sollte sich die Fehlermeldung eher im syslog statt im Xorg.log finden.

Falls du einen zweiten Rechner (oder Smartphone mit der passenden App) hast kannst du nach dem "hängen" noch versuchen per SSH (falls aktiviert) auf den Rechner zuzugreifen. Dann kann man den Fehlerzustand in "Echtzeit" sehen.

Das mit der SSH-Verbindung ist genial! ...ich weiß das zwar...hatte aber vergessen, dass ich es weiß...<hust>

Eine Frage dazu: Wie kann ich absolut sicherstellen, dass die ssh nur lokal, also im IP-Bereich meines lokalen Netzes (192.168....) erreichbar ist und keinesfalls von außen? Ich will nicht,
dass jemand auf meinem Rechner rumturnt...verständlicherweise...

Mit "normalem Systemlog" meinst Du den dmesg-Output, ja?

[Banana]

Code: Select all

vi /etc/ssh/sshd_config
ListenAddress 192.168.1.100 
- restart
- check with 
 netstat -tulnp | grep ssh

https://linux.die.net/man/5/sshd_config

[SkaaliaN]

Servus,

wenn du das Logfile postet, dann nicht nur das Xorg.log sondern auch den passenden Ausschnitt aus dem normalen System log. Wenn bspw. das NVIDIA Modul aussteigt, sollte sich die Fehlermeldung eher im syslog statt im Xorg.log finden.

Falls du einen zweiten Rechner (oder Smartphone mit der passenden App) hast kannst du nach dem "hängen" noch versuchen per SSH (falls aktiviert) auf den Rechner zuzugreifen. Dann kann man den Fehlerzustand in "Echtzeit" sehen.

Das mit der SSH-Verbindung ist genial! ...ich weiß das zwar...hatte aber vergessen, dass ich es weiß...<hust>

Eine Frage dazu: Wie kann ich absolut sicherstellen, dass die ssh nur lokal, also im IP-Bereich meines lokalen Netzes (192.168....) erreichbar ist und keinesfalls von außen? Ich will nicht,
dass jemand auf meinem Rechner rumturnt...verständlicherweise...

Mit "normalem Systemlog" meinst Du den dmesg-Output, ja?

Ich habe mein SSH damals mit AllowUsers user@ip sowie 2fa und Key abgesichert. Zudem kannst Du natürlich noch fail2ban für den ssh laufen lassen.
Im besten Fall hast Du natürlich noch eine opnsense oder pfsense im Netz. Dann machst Du da einfach den Port dicht / auf, wie es Dir passt.

[northfrisia]

Moin,

so, es hat wieder "geknallt" ... will sagen: Die Displayausgabe ist eingefroren, der Rechner "unten drunter" läuft anscheinend weiter.

Zum Zeitpunkt des Freeze lief gerade Blender und renderte fleißig vor sich hin...

Es ist diesmal aber ein untypischer, bisher nicht aufgetretener Fehler:

Code: Select all

[    5.407382] [drm] [nvidia-drm] [GPU ID 0x00002600] Loading driver
[    5.407386] [drm] Initialized nvidia-drm 0.0.0 for 0000:26:00.0 on minor 0
[    5.427976] usbcore: registered new interface driver cdc_ether
[    5.435256] usbcore: registered new interface driver cdc_eem
[    5.442328] usbcore: registered new interface driver cdc_subset
[    6.248720] nvidia-gpu 0000:26:00.3: i2c timeout error e0000000
[    6.248729] ucsi_ccg 0-0008: i2c_transfer failed -110
[    6.248734] ucsi_ccg 0-0008: ucsi_ccg_init failed - -110
[    6.248740] ucsi_ccg 0-0008: probe with driver ucsi_ccg failed with error -110

...was merkwürdig ist...aus dem Zeit des Auftretens des Fehler gemutmaßt, hätte ich gleich zu Anfang
gar kein X hochfahren können... ? Merkwürdig.

Ich habe versucht. die Log sinnvoll zu kürzen...sollte was Wichtiges dem zum Opfer gefallen sein...bitte melden...
dann poste ich eine Korrektur:

X.org.log: https://bpa.st/BEVA
dmesg: https://bpa.st/WOAQ

Vielleicht könnt ihr das was erkennen...?

Cheers!
Northfrisia

[northfrisia]

Moin,

...und wieder hat es "gefroren"... den Fehler aus dem Logs findet man mit sehr spärlich gestreuten Lösungen, die zu speziell sind, um sie zu übertragen,
in diversen Foren. Ich habe den Eindruck, dass NVidia darauf wenig reagiert.

Editierte Logs
Xorg.log: https://bpa.st/6QFQ

In dmesg.log und messages steht nichts Bemerkenswertes dazu.

Cheers!
Northfrisia

[haegar87]

Moin,

so, es hat wieder "geknallt" ... will sagen: Die Displayausgabe ist eingefroren, der Rechner "unten drunter" läuft anscheinend weiter.

Zum Zeitpunkt des Freeze lief gerade Blender und renderte fleißig vor sich hin...

Es ist diesmal aber ein untypischer, bisher nicht aufgetretener Fehler:

Code: Select all

[    5.407382] [drm] [nvidia-drm] [GPU ID 0x00002600] Loading driver
[    5.407386] [drm] Initialized nvidia-drm 0.0.0 for 0000:26:00.0 on minor 0
[    5.427976] usbcore: registered new interface driver cdc_ether
[    5.435256] usbcore: registered new interface driver cdc_eem
[    5.442328] usbcore: registered new interface driver cdc_subset
[    6.248720] nvidia-gpu 0000:26:00.3: i2c timeout error e0000000
[    6.248729] ucsi_ccg 0-0008: i2c_transfer failed -110
[    6.248734] ucsi_ccg 0-0008: ucsi_ccg_init failed - -110
[    6.248740] ucsi_ccg 0-0008: probe with driver ucsi_ccg failed with error -110

Servus,

die usci_ccg Fehler beim Booten würde ich als nicht relevant für dein Problem ansehen. (Vorsicht, persönliche Einschätzung!)

1. Müsste der Fehler dann sofort auftreten, da die Initialisierung bereits 6 Sekunden nach Rechnerstart auftritt.
2. Handelt es sich beim ucsi_ccg lediglich um den USB Typ-C Anschluss der Grafikkarte. Dazu wurde im NVIDIA Forum auch mal eine Erklärung gepostet:

Code: Select all

UCSI CCG Failures: This controller manages USB Type-C power delivery. Its inability to initialize likely explains why the device cannot be powered via USB-C and faces issues with the jack port.

Wundert mich aber das sowohl im syslog wie auch in dmesg nichts dazu steht. Dann dürfte ja nur der xorg-server betroffen sein auf Anwendungsebene. Dann dürfte aber der Rechner eigentlich nicht "einfrieren" und man müsste zumindest auf ein Terminal wechseln können.

[northfrisia]

Moin,

ich bin mal vorsichtig optimistisch...

Ich denke, das Problem ist beseitigt. Und die "Lösung" - sollte es sich herausstellen, dass das System weiterhin stabil bleibt - ist einfach zu banal, als das man da
sofort drauf kommt:

Code: Select all

1. Schritt - Rechner ausschalten, Netzkabel ziehen, Rechner wieder einschalten (Ja!) um die Caps zu entladen.
2. Schritt - Unter Einsatz aller Restsportlichkeit unter den Tisch kriechen und den Rechner öffnen.
3. Schritt - Die Schrauben lösen, mit der die Graka auf ihrem Sockel gehalten wird.
4. Schritt - Die Graka vorsichtig und unter Beachtung des Sperrhebel am Slotsockel entfernen.
5. Schritt - Das nächste Fenster öffnen und die Graka (nein - nicht aus dem Fenster werfen....) mit einem enstsprechenden Pustefix vom Staub befreien (das war nicht so allzu viel).
6. Schritt - Graka wieder einbauen - dabei beim Einstecken in den Sockel ruhig ein wenig hin- und her"schunkel" (die Graka natürlich...nicht selber schunkeln) um eventuelle dünne 
                Oxydschichten zu durchbrechen.
7. Schritt - Rechner wieder zuschrauben, Netzkabel stecken, Rechner einschalten.
8. Schritt - Blender starten, Animation durchrechnen lassen und gleichzeitig mit ghostty arbeiten - sonst ein absolut tödliches Unterfangen aber nun : Kein Freeze, kein garnichts. Alles gut

Ich setze den Thread bewußt noch nicht auf "Solved", da ich das Ganze noch beobachten möchte. Das kann aufgrund persönlichen Umstände noch mehrere Wochen dauern, bevor ich hier aus
technischen Gründen wieder etwas posten kann.
Gleiches gilt für den Thread, wo ich eine (manchmal nun doch nicht funktionierende) Lösung für ein Audio-Problem gepostet habe. Die Lösung funktioniert /manchmal/ eben dann doch nicht und
ich weiß noch nicht, warum.

Cheers!
Northfrisia

[firefly]

Klingt nach einem "Hardware" Problem bei dem wohl die GPU nicht 100% korrekt im PCI-E Sockel steckte und dabei nicht alle Pins ausreichend kontakt hatten.
Wodurch es dann zu Datenübertragungsfehlern kommen kann.