NVRM: gpuHandleSanityCheckRegReadError_GM107

Wenn Ihr mal so einen Fehler bei einer NVIDIA Karte:

… 1 Millionen Zeilen davor…
Dec 27 12:28:45 eve kernel: NVRM: gpuHandleSanityCheckRegReadError_GM107: Possible bad register read: addr: 0x110100, regvalue: 0xbadf5620, error code: Unknown SYS_PRI_ERROR_CODE
Dec 27 12:28:45 eve kernel: NVRM: gpuHandleSanityCheckRegReadError_GM107: Possible bad register read: addr: 0x110100, regvalue: 0xbadf5620, error code: Unknown SYS_PRI_ERROR_CODE
… und noch ein paar mal danach…

im Massen, und ich meine wie in „Sand-am-Meer“ oder „Sterne im All“ im Log seht und Euer Desktop nicht laden will, dann habt Ihr vermutlich ein PCI-Powerproblem an der Grafikkarte. Die GPU Kann dann nicht initialisiert werden und der Treiber wirft dann mit solchen Fehlern um sich und ich meine echt eine 7 stellige Zahl an Zeilen.

Ich habe gestern neues RAM in den PC eingesetzt und danach gabs keine Bootprobleme. Aber um das einsetzen zu können, mußten erst mal Stecker gezogen und Sache gereinigt werden:

Alle Jahre wieder…

Dabei „könnte“ es zu einem Steckerproblem gekommen sein, deswegen nicht mehr genug Saft an der Graka an kam.

Mein Ansatz war, weil der PC ja ansonsten noch lief, sonst wäre ich nicht an den Fehler gekommen, mal das Netzteil prüfen, gucken was passiert, wenn eine andere Graka drin ist usw.. Dafür mußten alle Stecker vom Netzteil ab, dann wurde auf Netzteil Kurzschluss gelauscht ( das könnte knistern ) und dann wurde alles wieder zusammen gebaut und nach und nach angeschlossen, um die defekte Komponente zu finden.

Klingt gut, so steht es im 1×1 der PC Reparatur, aber da bis auf das Bild vorher alles da war ohne rumzuzicken, lag das Augenmerk natürlich auf der Graka, auch wenn wirklich alle Stecker vom Netzteil ab waren, und was soll ich Euch sagen.. er bootete, als wenn nie was gewesen wäre. Vielleicht ist das auch nur die Ruhe vor dem Sturm und ich brauche bald ein neues Netzteil. Ihr werdet es erfahren.

Nachtrag: 31.12.2025

Neben den „Verkabelungsproblemen“ kam noch ein anderer Faktor hinzu. Das Alte RAM hatte „Aussetzer“, spricht, es war entweder inkonsequent defekt, oder mit Spannung unterversorgt, was bei RAM Bausteinen schon mal passieren kann, wenn die Stromversorgung des Mainboards knapp ist. Deswegen kann man im BIOS den Rambänken mehr Spannung geben, was zu mehr Leistung führt und die „Aussetzer“, die meist einen Reset auslösen, minimieren. So war das bei meinem alten RAM auch. 1.430V auf dem DDR4-3200 Ramriegel war im Bios eingestellt, womit die „Aussetzer“ auf wenige Tage im Jahr beschränkt waren. Die „Aussetzer“ waren auch ein Grund für neues Ram 😉

Wenn man vergißt das wieder auf Standard zu setzen, dann bekommen die neuen, dickeren RAM Streifen zu viel Energie und können zu a) mehr Stromverbrauch führen und b) selbst wieder Aussetzer auslösen. Und das ist dann auch passiert. Seit die Spannung im Bios auf Normal zurückgesetzt wurde, läuft der Rechner mit dem neuen Ram wieder zuverlässig. Ob die Resets jetzt auch aufgehört haben, kann nur die Zukunft zeigen.

Genug RAM gibt es gar nicht…

“ ‚Auf der Suche nach der Wahrheit, muß der Adept allerlei Prüfungen des Geistes und Körpers über sich ergehen lassen.‘ „Prüfungen kann ich ertragen, Meister, aber an Langweile werde ich sterben.“ “ ( aus den Büchern Groths )

So geht es mir auch grade 🙂 Ich bin auf der Suche nach der Wahrheit hinter einem DNS Fehler, aber diese Wahrheit bedeutet Stress pur. Bosten läuft zum dritten Marathon durch, und kein Ergebnis, dafür aber Heldenleistungen bei den Prozesswerten.

Dabei fing alles mit einer harmlosen Frage an :

Bluefish3

Sehr lang ist noch milde ausgerückt, denn SQL Dumps werden von MySQLdumper dummerweise so gemacht, daß sie riesige Anweisungsketten sind, die mit einem einzigen INSERT mal ebend hunderttausende bis Millionen von Tabellenzeilen schreiben. Der MysqlServer schafft das deutlich besser als BlueFish 🙂

Wie man hier schön sehen kann, sollte ein Texteditor so nicht in der Prozessliste aussehen:

3.7 GByte RAM verbrauch für ein 2 GB SQL File

3.7 GByte RAM verbrauch für ein 2 GB SQL File

Und seit ca. 20 Minuten sieht man das Bild :

Bluefish2
Keine Ahnung was am Laden von 2 GB Text so viel CPU ziehen kann 😉  Sehr positiv, der Rest vom System reagiert noch richtig gut 🙂 Wozu hat man auch 8 Kerne ? Die langweilen sich ja sonst eh den ganzen Tag.

Nach 30 Minuten glaube ich langsam daran, daß sich …. nein… jetzt, fertig? Dramatik bei BlueFish.. RAM Verbrauch droppt von 3.7 GB auf 1.9 GB , aber dafür mußte etwas ausgelagert werden.. Gnome ist jetzt leider der Meinung, daß BlueFish nicht mehr auf Eingaben reagiert ( stimmt ), und möchte es terminieren, aber Bluefish ackert noch 😉  … Eine Geduldsprobe sonders gleichen..  Das Bluefish verloren hat, weil mir der Geduldsfaden geplatzt ist 🙂

Alternativen sind gefragt !

Die Anwendungen im Desktop sind alles Luschen, da müssen die Kollegen von der Bash ran 🙂

3 Minuten zum Entpacken des SQL Dumps von BZIP2 in Rohtext.
1 Sekunde zum Prüfen mit head, daß kein use database; im Dump steht.
10 Sekunden um zu sehen, daß der SQL beim Einsortieren die gesuchte Tabelle bereits eingefügt hat
10 weitere Sekunden um einen Select laufen zu lassen, der die gesuchten Informationen ausgibt.

In your Face DESKTOP ! 😀

Und das alles nur, weil der (sich beschwerende ) Kunde, seinen SOA Eintrag selbst gelöscht hat.

Was lernen wir daraus ?

  1. Ein Boston mp3 alleine macht noch keine gute Musikschleife
  2. Überbewerte Deinen Texteditor nicht, er ist nur für typische Desktopanwendungsfälle gemacht
  3. Bash rulz!