[SOLVED] kernel: qm[xxxxxx]: segfault at

[PikAss]

Hallo again,

ich hab hier mal wieder was für euch in der Hoffnung mir kann geholfen werden.

Jan 19 20:33:42 HomeLab kernel: qm[258790]: segfault at 7987cf401f92 ip 00007985d7e79305 sp 00007ffce8b480d0 error 4 in ld-linux-x86-64.so.2[7985d7e6c000+25000] likely on CPU 0 (core 0, socket 0)
Jan 19 20:33:42 HomeLab kernel: Code: 08 48 8b 85 60 ff ff ff 48 8b bd 78 ff ff ff 48 8b b5 58 ff ff ff 4c 89 f2 48 03 33 45 89 f5 48 c1 ea 20 48 89 b5 70 ff ff ff <0f> b7 04 50 48 8d 14 52 4c 8d 24 d7 25 ff 7f 00 00 4c 89 65 80 48
Jan 19 20:33:44 HomeLab kernel: qm[258796]: segfault at 73e59a801f92 ip 000073e3a3285305 sp 00007ffffc4801e0 error 4 in ld-linux-x86-64.so.2[73e3a3278000+25000] likely on CPU 2 (core 2, socket 0)
Jan 19 20:33:44 HomeLab kernel: Code: 08 48 8b 85 60 ff ff ff 48 8b bd 78 ff ff ff 48 8b b5 58 ff ff ff 4c 89 f2 48 03 33 45 89 f5 48 c1 ea 20 48 89 b5 70 ff ff ff <0f> b7 04 50 48 8d 14 52 4c 8d 24 d7 25 ff 7f 00 00 4c 89 65 80 48
Jan 19 20:33:46 HomeLab kernel: qm[258805]: segfault at 7e9921201f92 ip 00007e9729df4305 sp 00007ffdcda265c0 error 4 in ld-linux-x86-64.so.2[7e9729de7000+25000] likely on CPU 2 (core 2, socket 0)
Jan 19 20:33:46 HomeLab kernel: Code: 08 48 8b 85 60 ff ff ff 48 8b bd 78 ff ff ff 48 8b b5 58 ff ff ff 4c 89 f2 48 03 33 45 89 f5 48 c1 ea 20 48 89 b5 70 ff ff ff <0f> b7 04 50 48 8d 14 52 4c 8d 24 d7 25 ff 7f 00 00 4c 89 65 80 48
Jan 19 20:33:48 HomeLab kernel: qm[258811]: segfault at 7c888e801f92 ip 00007c86972a1305 sp 00007ffdf95d5860 error 4 in ld-linux-x86-64.so.2[7c8697294000+25000] likely on CPU 2 (core 2, socket 0)

Diese Fehlermeldungen sind durchgehend bis jetzt, jede Sekunde ein neuer Eintrag, auch immer mit unterschiedlichen Core, socket Angaben.

Am Sonntag abend (als der Fehler zum ersten Mal auftrat) habe ich nicht wirklich bewusst etwas getan. Ich hatte am Sonntag angefangen von einer ntfs HDD Daten auf eine TrueNAS VM mit ZFS Raid zu kopieren. Die TrueNAS VM bekommt einen PCIe SAS Controller durchgereicht und lief bis dahin stabil.
Heute morgen konnte ich mich nicht mehr per Konsole auf die TrueNAS VM connecten, per ssh ging auch nichts aber auf die WebUI von TrueNAS selbst schon.
Das Dashborad dort zeigte keine Fehler an und auch die Logs waren okay.
Ich habe dann von dort aus die VM heruntergefahren und wollte zum testen ein Backup der TrueNAS VM zurückspielen.

Beim Klick auf "zurückspielen" kommt dann ( jedem Backup der TrueNAS VM)

Failed to extract config from VMA archive: /bin/bash: line 1: 1511436 Exit 70 zstd -q -d -c /mnt/lvmdir/dump/vzdump-qemu-103-2025_01_22-02_00_05.vma.zst (500)

Dann wollte ich wegen dem Backup Fehler einer Anleitung aus dem Forum folgen die erstmal ein Update vorraussetzt. Wenn ich über die GUI ein Update starten will:

()
starting apt-get update
TASK ERROR: command 'apt-get update' failed: got signal 11

Wenn ich über die Shell ein apt update machen will

Segment fault

Während ich angenfangen habe den Post zu schreiben, wollte ich noch die anderen VM herunterfahren um proxmox mal neu zu starten, inzwischen geht über die proxmox GUI immer weniger und auch die Shell reagiert nicht mehr.

 

[PikAss]

Update:
Nach einem hartem neu start des Systems, scheint alles erstmal normal zu laufen. Erklärt aber nicht, wie es zu dem Fehler kam.

 

[ThoSo]

Hardware (schon beschafft und im Testrun):
Mainboard: Gigabyte MC12-LE0
RAM: 2 x 16 GB SAMSUNG UDIMM DDR4 mit ECC
CPU: AMD Ryzen 4650G PRO
PCIe: LSI 9300-8i in HBA / IT Mode geflashed

Aus den anderen Beitrag mal kopiert

Der segment fault ist ein Absturz deiner Bibliothek in der Fehlermeldung und die Reaktion darauf scheint das Verhalten von Proxmox zu sein. Könnte am Speicher liegen, vielleicht wurde der mal vollständig benutzt.
Könntest mal einen memtest laufen lassen, bzw. Bei GA nach updates für Bios prüfen. Gibt es im bios ein log?

 

[PikAss]

Im BIOS gibt es keinen Log dazu, da sieht alles normal aus. Ein neuers BIOS als das was ich habe gibt es auch nicht.
Welche Biliothek meinst du?
Die CPU Bibliothek?
Kann man das irgendwie abfangen?

Ich habe zufälligerweise im TrueNAS dann doch einen Eintrag gefunden, der sich schon öfter gezeigt hat.

truenas.local had an unscheduled system reboot. The operating system successfully came back online at

Das hab ich mal gegoogelt und ich bin zumindest nicht der einzige, ggf. ist hier die TrueNAS VM der Übeltäter.

 

[ThoSo]

Diese : error 4 in ld-linux-x86-64.so.2[73e3a3278000+25000]

Wenn das am TrueNAS liegt mal bei deinen das Forum checken

 

[PikAss]

Könnte am Speicher liegen, vielleicht wurde der mal vollständig benutzt.

Vielleicht ne komische Frage aber:
Wie verhindere ich das?
Zu dem Zeitpunkt gab es nur 1 VM und 2 LXC
Die VM hatte 16 GB die LXC jeweils 4 GB
Habe inzwischen 64 GB RAM (4 von den Modulen aus dem Hardwarepost)

Das kopieren von Daten ballert den zfs Cache bei TrueNAS ordentlich hoch, dieser läuft im RAM. Aber ich habe heute nochmal einen Riesen Schwung Daten kopiert. Das Dashboard in TrueNAS zeigte 12 GB zfs Cache währenddessen an. 16 GB hat die VM. Beschwert hat sich nichts, Fehler gab es auch keine währenddessen.

memtest war wieder ok

 

[PikAss]

Auch nach einer neu Installation habe ich Fehler in dieser .so Datei.

kernel: traps: 9[430467] general protection fault ip:7165c19a390c sp:7ffd3de0b320 error:0 in ld-linux-x86-64.so.2[7165c1995000+2b000]

Dafür ohne den Zusatz mit der CPU wie bei dem geposteten oben.
Gestern Abend z.B. häuften sich die Fehler im Log als wir einen Film über Jellyfin (LXC) angesehen haben. Kann es vielleicht irgendwas mit den IOMMU von AMD zu tun haben?
Ich habe ja nur die integrierte Grafik von Ryzen4650g der das alles leisten soll und auch eigentlich auch leisten könnte.
Oder gibt es vielleicht einfach ein generelles Problem mit der CPU und dieser Bibliothek?
Ich werde daraus nicht schlau und weiß auch nicht wie das mal richtig testen könnte.

 

[PikAss]

Ich habe die letzten Tage mit CPU Stresstests und ausführlichen memtests vollbracht.
Siehe da, es hat (irgendwie) was gebracht.



Beim Test 13 - Hammer test versagen wohl so ziemlich alle RAM`s, daher kann man das Ergebnis vielleicht noch unbeachtet lassen.
Seltsam ist, ich habe inzwischen ingesamt 8 Läufe mit unterscheidlichen memtest Versionen gemacht, aber die Fehler sind nicht bei jedem Test aufgetaucht. Daher dachte ich auch nach den ersten Tests die erfolgreich waren und die ich ja schon gemacht hatte, der RAM wäre in Ordnung.
Der wiederkehrende Fehler in der lib6c und die aktuellen Ergebnisse, deuten aber dann wohl doch einen defektem RAM hin.

Zumindest hoffe ich das irgendwie, weil ich nun nicht mehr weiß was ich noch testen kann und wie ;-)

 

[ThoSo]

Du könntest den Speicher mal reduzieren und versuchen herauszufinden, ob sich das auf ein Modul eingrenzen lässt (für die Garantie).
Ich gehe mal davon aus, das du BIOS Firmware auf dem neusten Stand hast.

 

[PikAss]

Das Board lässt immer nur Speicherpaare zu, müsste also ziemlich viele Kombinationen fahren. Außerdem schlägt ja nicht jeder Test fehl. Ich habe beim Verkäufer angefragt was ich jetzt machen kann und die Bilder mitgeschickt. Mal abwarten.

BIOS Firmware ist das aktuelles was es von Gigabyte gibt für das Board.

 

[PikAss]

Sorry für die lange Pause, aber es hat sich einiges getan.
Ich habe den RAM, das Board und die CPU getauscht. Vorab hab ich mir eine alte Workstation von der Arbeit mit genommen und darauf auch nochmal eine PVE Installation gemacht. Siehe da, reibungsloser Betrieb für eine Woche, 0 Fehler etc. bei gleicher Konfiguration und gleichen VM`s.

Ich habe nun mit der neuen Hardware ebenfalls einen Test hinter mir und inzwischen bin ich "produktiv" ohne Fehler.

Vielen Dank für den Support, ich markiere den Thread als gelößt.