Verbindung zum NVME-Modul reißt ab

    • New

    Ein fröhliches Hallo an alle Raspi-Freunde

    Nachdem die (üblichen) Startschwirigkeiten überwunden waren, habe ich meine Nextcloud auf dem CM5 installiert.

    Beim Kauf der Komponenten war ich mir nicht sicher, wie der SDRAM auf dem CM5 angesprochen wird (Geschwindigkeit), und habe mir zusätlich ein NVME-Modul zugelegt. Dies wollte ich dann als Ersatz für die sonst übliche SD-Ram- Karte nutzen. Das war mal :)

    ich habe 'ROOT' und 'BOOT/FIRMWARE' auf den mmcblk, das 'HOME' ist Part 1 der NVME und das Web (ohne data) ist Partition 2 der NVME. Hinzu kommen noch 2 externe HDD zur Aufnahme der Nextcloud - DATA, sowie ein SMB-Shared fürs Heimische Netz und auf der 2. Platte läuft nachts Backup


    So weit so gut.

    Nach der Fertigstellung aller Einstellungen stellte sich nach 2 - 3 Tagen Laufzeit ein Fehler ein. Über nacht ist der PI ausgestiegen. Nach dem Neustart konnte ich nur noch sehen, dass Kernel-Panik ausgelöst wurde. Zu diesem Zeitpunkt hatte ich noch eine SWAP-Partition auf der NVME. Und ein fehlender SWAP löste den Fehler aus.
    Nagut, kann schon mal passieren. SMART zeigte keinerlei Fehler beim Schreiben oder lesen, aber einen Verbindungsabriss. Ergo dachte ich mir, der Pi hat sich 'verschluckt'

    Nach 2 Tagen wieder das gleiche Problem. Cirka 04:00 Uhr Kernel-Panik kann nicht auf SWAP zugreifen.

    Also habe ich sicherheitshalber auf der ext. HDD einen SWAP eingerichtet und eingebunden. Aber das kann es ja nicht alleine gewesen sein.

    Dann kam mir der RP1 in den Sinn. Wird der zu heiß, und schaltet sich ab? Also mir die Temperatur vom RP1 angeschaut. Ui, ca. 65°C. Sodann wurde ein passender Kühlkörper erworben, und seit dem lümmelt sich der RP1 bei ca. 54°C rum. (Checked)

    Nun kommt der Dämpfer.

    Heute ... vor ca. 1,5 Stunden ... Fehler .. zum Glück nicht Kernel-Panik :)

    ABER

    das ist das Protokoll. Es beginnt mit dem letztem geglücktem Zugriff (Nextcloud Cron-Job aus /var/www/nc welches auf NVME0 gemountet ist)

    Und danach kommt der Ausstieg. Was ich mich frage, was meint das LOG nun mit Controller ist down. Ist das die Schnittstelle auf dem NVME Modul, oder die Schnittstelle im RP1 ?

    Gibt es eine Möglichkeit zu Testen, welches Produkt hier welchen Fehler hat? Oder ob ich ein Timing-Problem habe ?

    Code
    cloud-adm@raspberrypi:~ $ lspci
0000:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 30)
0000:01:00.0 Non-Volatile memory controller: Silicon Motion, Inc. SM2263EN/SM2263XT SSD Controller (rev 03)
0001:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 30)
0001:01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge

    Genutzt wird ein 250 GB Intenso Modul Firmware "X0304B0"
    (Infos aus /sys/class/nvme
    address = 0000:01:00.0
    cntlid = 1
    cntrltype = reserved
    dctype = none
    dev = 245:0
    firmware_rev = X0304B0
    kato = 0
    model = Intenso SSD
    numa_node = -1
    queue_count = 5
    serial = TD24090001*** (Seriennummer)
    sqsize = 255
    state = dead
    subsysnqn = nqn.2024-09.com.siliconmotion:nvm-subsystem-sn-TD24090001*** (siehe oben)
    transport = pcie
    uevent = MAJOR=245
    MINOR=0
    DEVNAME=nvme0
    NVME_TRTYPE=pcie


    Kennt oder hatte schon mal jemand diesen Fehler ?

    Als Workaround wird das NVME erstmal auf eine HD ausgelagert, bis das ich weiß wie der Fehler entsteht.


    [EDIT1]

    Während ich diesen Beitrag verfasst habe, scheint sich das System erholt zu haben.

    Ich habe folgenden Bereich aus dem LOG

    Code
    Mar 09 17:02:35 raspberrypi sudo[1245242]: cloud-adm : TTY=pts/3 ; PWD=/home/cloud-adm ; USER=root ; COMMAND=/usr/bin/find / -iname ksystemlog
Mar 09 17:02:35 raspberrypi sudo[1245242]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
Mar 09 17:02:35 raspberrypi kernel: EXT4-fs warning (device nvme0n1p2): htree_dirblock_to_tree:1083: inode #2: lblock 0: comm find: error -5 reading directory block
Mar 09 17:02:38 raspberrypi kernel: EXT4-fs warning (device nvme0n1p1): htree_dirblock_to_tree:1083: inode #2: lblock 0: comm find: error -5 reading directory block
Mar 09 17:02:40 raspberrypi sudo[1245242]: pam_unix(sudo:session): session closed for user root
Mar 09 17:05:01 raspberrypi CRON[1246613]: pam_unix(cron:session): session opened for user www-data(uid=33) by (uid=0)

    [/EDIT1]

    Edited once, last by PromiseYou (March 9, 2025 at 6:35 PM).

    • New

    Ich habe einen cm4 - also keinen 5er - mit folgender Konfig:

    Code
    pi@raspberrypi-bookworm-64-lite-cm4-nvme:~ $ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk0      179:0    0  29.1G  0 disk 
├─mmcblk0p1  179:1    0   512M  0 part 
└─mmcblk0p2  179:2    0   3.2G  0 part 
mmcblk0boot0 179:32   0     4M  1 disk 
mmcblk0boot1 179:64   0     4M  1 disk 
nvme0n1      259:0    0 119.2G  0 disk 
├─nvme0n1p1  259:1    0   512M  0 part /boot/firmware
└─nvme0n1p2  259:2    0 118.7G  0 part /

    So wie ich verstehe dast Du eine ebensolche Konfig - nur eben auf cm5. Ich betreibe den cm4 mit einem normalen USB Netzteil ohne Probleme. Ich vermute mal dass der cm5 bzgl Power anspruchsvoller ist. Von daher könnte ich mir vorstellen dass Deine Stromversorgung nicht stabil genug ist. Die Fehlermeldungen im Log zeigen dass de NVMe Speicher Probleme macht. Kann natürlich auch sein dass der Speicher nicht OK ist. Ich würde jedenfalls erst mal prüfen was der cm5 für eine Stromversorgung lt Spec benötigt und dafür sorgen dass die Anforderungen erfüllt sind.

    :no_sad: ... Kein raspiBackup - kein Mitleid ... :no_sad:

    Wenn dann Dir raspiBackup den Ar*** gerettet hat

    solltest Du fairerweise diese Seite besuchen und ein Trinkgeld spendieren :shy:

    Mein Raspberry Zoo

    3 * RPi1B, 2 * RPi3B, 2 * RPI4, 1 * CM4, 1 * RPi5

    • New
    Quote from framp

    Ich würde jedenfalls erst mal prüfen was der cm5 für eine Stromversorgung lt Spec benötigt und dafür sorgen dass die Anforderungen erfüllt sind.

    Das CM5 braucht genauso wie der Pi5 ein Netzteil mit 5V 5A. (Angaben laut Datasheet Punkt 2.14
    Im Set werden die auch mit dem Netzteil des Pi5 "27W" angeboten.

    Hier das offizielle Datasheet

    • New

    Das Netzteil ist das original Netzeil der Foudation (weiß Quader 27 Watt) mit Himbeer-Logo vom offiziellen Reseller. Das ursprüngliche 30 Watt Netzteil von Waveshare machte Probleme, weshalb ich sofort auf das Originale zugreife.

    Die HDD's befinden sich auch an einem HUB, so dass hier kein Strom abgezapft wird.

    #framp

    Yap ... ist ähnlich :)

    meine fstab

    im unterem Bereich sind auskommentiert alle Bezeichnungen, welche mir blkid lieferte, und sie Übersichtshalber so plaziert habe

    meine /boot/firmware/contig.txt

    Status NVME

    [EDIT] es wurde smart-Status nachgepostet [/EDIT]

    • New

    Ok. Dann liegt es wohl nicht an der Power (Ich nehme an Du nutzt einen aktiven USB Hub :green_smile:)

    Hat wohl jetzt nichts mit dem eigentlichen Problem zu tun - aber es verwundert mich dass Du den Swap auf die sda mit 40GB gelegt hast. Warum nicht auf die NVMe? Die ist definitiv schneller. Auch sind 40GB wohl etwas überdimensioniert :shy:

    :no_sad: ... Kein raspiBackup - kein Mitleid ... :no_sad:

    Wenn dann Dir raspiBackup den Ar*** gerettet hat

    solltest Du fairerweise diese Seite besuchen und ein Trinkgeld spendieren :shy:

    Mein Raspberry Zoo

    3 * RPi1B, 2 * RPi3B, 2 * RPI4, 1 * CM4, 1 * RPi5

    • New
    Quote from framp

    Ok. Dann liegt es wohl nicht an der Power (Ich nehme an Du nutzt einen aktiven USB Hub :green_smile:)

    Hat wohl jetzt nichts mit dem eigentlichen Problem zu tun - aber es verwundert mich dass Du den Swap auf die sda mit 40GB gelegt hast. Warum nicht auf die NVMe? Die ist definitiv schneller. Auch sind 40GB wohl etwas überdimensioniert :shy:

    yup .. ist nen aktiver hub

    Hatte zuvor den swap auf der NVME (steht auch noch in der fstab, und die PART ist auch noch da. (8GB)
    Als dann der Kernl PANIK bekam, weil er nicht mehr swappen konnte, und es bei mir frostig wurde :)

    Deshalb habe ich mir von den vorhanden partitionen vorne und hinten etwas abgeknabbert, um in der Mitte dann die swap zu haben.

    naja, ich scheine mich um eine 10er potenz verschätzt zu haben :) .. es sollten 4 GB werden nicht 40 ;) war mir dann aber erstmal egal. Dachte ja, dass das swappen den RP1 heiß werden lässt, und das wollte ich ausschalten. Jedoch weiß ich nun, es hat nix mit dem swap zu tun.

    • New

    Die Fehlermeldungen zeigen ziemlich sicher entweder auf Powerprobleme oder NVMe Probleme hin. Vielleicht ist der NVMe nicht offiziell supported von CM5? Wenn ich mich nicht irre gibt es hier im Forum eine Liste von funktionierendem NVMe Speicher auf der RPi5. Die sollten wohl auch bei dem CM5 funktionieren.

    :no_sad: ... Kein raspiBackup - kein Mitleid ... :no_sad:

    Wenn dann Dir raspiBackup den Ar*** gerettet hat

    solltest Du fairerweise diese Seite besuchen und ein Trinkgeld spendieren :shy:

    Mein Raspberry Zoo

    3 * RPi1B, 2 * RPi3B, 2 * RPI4, 1 * CM4, 1 * RPi5

    • New
    Quote from framp

    Die Fehlermeldungen zeigen ziemlich sicher entweder auf Powerprobleme oder NVMe Probleme hin. Vielleicht ist der NVMe nicht offiziell supported von CM5? Wenn ich mich nicht irre gibt es hier im Forum eine Liste von funktionierendem NVMe Speicher auf der RPi5. Die sollten wohl auch bei dem CM5 funktionieren.

    da habe ich das gefunden:

    Thread

    Raspberry Pi 5 HAT+ und SSD NVMe-Kompatiblitätsliste

    Hallo an Alle,

    schon seit einiger Zeit wünsch ich mir ne Übersicht, welche NVMe -SSDs mit welchen HAT + auf dem 5er booten, laufen, rennen und welche es nicht tun.
    Klar kann man das Forum durchforsten, aber schon allein der wunderbare Artikel über die "magischen" SSD -Adapter zeigt, wie hilfreich es ist, wenn man eine einheitliche Anlaufstelle findet. Und weil ich der Meinung bin, mit "nicht motzen - machen! :thumbsup1:" kommt man weiter.

    Auch gleich noch ne Anmerkung zur Stromversorgung:
    laut Geekworm ist…
    McDotter
    November 27, 2024 at 4:00 PM

    danach haben die 'besseren' module (wie auch die EVO) bei den controllern 01, 02 und 03 Probleme. Da mein I/O Board das von Waveshare ist, denke ich, die haben überall die gleichen Chips verbaut, und somit werde ich mal schauen, ob ein gelistetet Modul abhilfe verschafft.

    Was jedoch interessant ist, der Status 'Unsafe Shutdowns' hat sich bei den letzten 3 Ausfällen nicht erhöht.
    Die 76 stammt von der Einrichtung, bis ich das System das erste Mal stabil hatte (siehe Forum-Beitrag 'CM5 mit 32GB eMMC bootet nicht nach systemcrash')

    Die Spannungen überwache ich mit netdata, und dort ist kein Spannungsabfall zu beobachten.

    In der Anleitung der Foundation steht etwas wegen Gen3 sei noch nicht 100%. Dann finde ich aber wieder Einstellempfehlungen mit eingeschaltetem Gen3

    Kann auch hier der Fehler her kommen? Ist das für die Hardware im Timing ein großes Problem? (Ich kenne nur die damaligen Timing-Probleme bei SD-RAM mit entsprechenden Schreib und Lesezyklen, und wie die im Einklang mit dem Systemclock zusammen zu bringen sind).
    Stelle mir auch hier so etwas vor. Wait-State oder so.

    • New

    Deine Partitionierung von /dev/sdb und Deine (/etc/fstab)-mounts in #5 sind grauslig.

    -/dev/sdb hat überhaupt keine Partition für das EXT4 Filesystem (BACKUP)
    -/dev/sda2 kollidiert mit /dev/nvme0n1p2
    -/dev/sda3 ist viel zu groß

    Dazu gesellt sich noch ein Zeichensatzfehler.

    Servus !

    RTFM = Read The Factory Manual, oder so

    • New
    Quote from RTFM

    Deine Partitionierung von /dev/sdb und Deine (/etc/fstab)-mounts in #5 sind grauslig.

    Das ganze System ist grauslig eingerichtet, und das ist noch nett ausgedrückt.
    Ich jedenfalls blicke da nicht mehr durch. :(

    • New

    yap, stimme ich zu!


    ABER

    dieses Chaos hat NICHTS mit dem Fehler zu tun. Also schon sehr OT :/

    Um aber diesem "Chaos" etwas Deutlichkeit zu schaffen habe ich die Fehlerhaft eingerichtete SDB mit einer neuen Partion-Table versehen, und dort auch eine 'ordnungsgemäße' Partition eingerichtet. Diese befindet sich nun mit PARTUIID eingebunden als BACKUP

    Dann bleibt nur der 'unschöne Fehler', dass das Verzeichnis 'data' als MOUNTPOINT und nicht als BIND ingebunden ist.

    Ja, daran arbeitet ich, aber ich habe noch nie mit -bind gearbeitet, so dass mein nächster Schritt ist.

    Aber wie bereits gesagt, dieses alles hat nix mit dem Aussetzen des NVME zu tun :/

    Hier nun meine neue fstab:

    Ja, die SWAP ist noch bei 40GB und damit zu groß ... i know ....

    • New

    Sind das bei den externen HDDs wirklich PARTUUID oder sind das nicht UUID?

    Wenn UUID, dann sollte das auch dort so stehen!

    Um welches Board für das CM5 handelt es sich eigentlich und welchen USB-Hub hast Du um Einsatz?

    • New

    Ja, ich habe alles mit PARTUUID gemacht

    Code
    blkid
/dev/mmcblk0p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="5DC7-F115" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="ff37a851-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="a36be96c-66be-4487-a7a6-0481bca99d89" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ff37a851-02"
/dev/nvme0n1p1: LABEL="pi_Home" UUID="b1c5525c-1f66-4579-b876-9cc8a7f643ca" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d2c3b34c-01"
/dev/nvme0n1p2: LABEL="nextcloud_Arbeit" UUID="51db2ae0-66ea-42ef-b89e-bde69c4c1fcc" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="d2c3b34c-02"
/dev/nvme0n1p3: UUID="e1894d22-5d3c-4d21-9fff-caccd7810b5e" TYPE="swap" PARTUUID="d2c3b34c-03"
/dev/sda1: UUID="ad443d5c-a69b-416a-be20-4a158dc6809f" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="SMB" PARTUUID="763a960a-8b14-4f65-bcd3-237c0fe20edf"
/dev/sda2: UUID="81bbbed4-65d1-4e6d-855a-d31258d9d6ac" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Nextcloud" PARTUUID="2c603593-83b9-4e75-8a87-204d45a08dba"
/dev/sda3: LABEL="SWAP" UUID="9ca2e6bd-4140-4b85-bb5e-214e83fcaed8" TYPE="swap" PARTLABEL="SWAP" PARTUUID="e1ecdc93-9a1b-4e78-ab23-f9f9efbee4f8"
/dev/sdb1: UUID="d9d0be7e-7810-4d8a-9fb6-538ab5bffd14" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="3cfbe86c-f911-4b26-a38d-0f7f3924234a"

    Und ja, die PARTUUID auf der SDA sehen wirklich blöde aus.

    Was ich auf jeden fall nicht hatte, waren die Einträge in der config.txt. (dtparam=pciex1 sowie dtparam=pciex1_gen=3)

    Da der Fehler ja nur alle paar Tage mal auftaucht, warte ich nun mal ab, ob der Fehler wieder auftaucht. Vielleicht habe ich mich bis dahin auch in das Einbinden von Verzeichnissen eingearbeitet.

    • New

    Trotz der bisherigen Infos vermute ich dennoch das selbe, was ich in #2 schrieb. Beantworte doch bitte auch diese Fragen:

    Quote from hyle

    Um welches Board für das CM5 handelt es sich eigentlich und welchen USB-Hub hast Du um Einsatz?

    Man weiß ja nie, was einem dazu hier noch einfällt.

    • New

    Das Board ist von Waveshare: https://www.waveshare.com/cm5-poe-base-a.htm jedoch ohne dem Netzteil. Hier wird das original 27 Watt Steckernetzteil verwendet.

    USB

    Das müssten die benötigten Infos beinhalten. Nachfolgend 'lsusb', wo der BUS 4 wohl den HUB repräsentiert. Device 2 und 4 sind die Platten, als müsste 1 und 2 zum Controller des HUB gehören (so geraten nicht gewußt)

    Angeschlossene Peripherie: USB-Hub aktiv von 'orico', daran 2* USB HDD M3 Portable von Seagate / Maxtor
    der Hub wird seit ca. 8 Jahren an PI's (3B und 4) betrieben, und wurde angeschafft, weil 2 andere HUB's probleme machten, und dieser hier noch nie. Somit gehe ich hier von einer vollen Kompatibilität aus.

    Code
    Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 004: ID 0bc2:61b5 Seagate RSS LLC Maxtor HX-M201TCB [M3 Portable 2TB]
Bus 004 Device 003: ID 0bc2:61b5 Seagate RSS LLC Maxtor HX-M201TCB [M3 Portable 2TB]
Bus 004 Device 002: ID 2109:0813 VIA Labs, Inc. VL813 Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 2109:2813 VIA Labs, Inc. VL813 Hub
Bus 003 Device 002: ID 1a86:8091 QinHeng Electronics USB HUB
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login