RevPi Connect+ Power LED blinkt/flackert rot - keine Verbindung mehr möglich

[energiemanagement]

Hallo Forum,
ich habe einen RevolutionPi Connect+ 8GB welcher über das bei Kunbus verfügbare Hutschienen Schaltnetzteil angeschlossen ist. Erweitert wurde das Gerät mit einem DATA IO und mit einem CAN Modul.
Das System läuft seit etwa 3-4 Monaten kontinuierlich und zuverlässig durch. Es gab nur sehr wenige und kleinere Softwareupdates. Vor etwa 2 Wochen war das System nicht mehr erreichbar. Soweit ich mich erinnere hat
am RevPi Connect+ die Power LED rot geblinkt. Ich habe das System stromlos geschaltet, wieder gestartet und dann lief es wieder einwandfrei. Eine erste Analyse lies vermuten, dass der Datenbank Prozess "heißgelaufen" ist, da mittlerweile 500MB Daten aufgelaufen sind und der Datenbankprozess fast 2 Kerne vollständig ausgelastet hat. Ich habe die Datenbank gelöscht, CPU war danach wieder am "idlen". Heute (2Wochen später) war das System schon wieder nicht mehr erreichbar. Die Power LED hat sehr unregelmässig rot geblinkt, ich möchte fast sagen "geflackert". Zusätzlich waren die LEDs A1 und A2 grün (nicht von mir geschaltet).
System stromlos geschaltet, wieder hochgefahren und nun läuft alles wieder (auch ohne merkliche CPU Last), aber:

Wieso stürzt der RevPi nach 3-4 Monaten 2 mal innerhalb von 2 Wochen ab? Warum blinkt die Power LED rot? Wie kann ich herausbekommen, was da passiert ist? Die Dokumentation schweigt dazu. Die Power LED vom DIO Modul war grün. Die Logfiles zum entsprechenden Zeitpunkt helfen nicht weiter. Das System ist ein Testsystem ohne Watchdog (der wird im Produktivbetrieb aktiviert). Trotzdem würde ich gerne herausbekommen, was dort passiert ist, denn eine Hardware die schon nach 3 Monaten abstürzt ist für meinen Anwendungsfall kritisch zu betrachten.

Das Flash des Systems wurde sehr freizügig vollgeschrieben. Im System sind derzeit noch 2GB frei, dennoch dürfte ich insgesamt schon 8GB vollgeschrieben haben. Meine Befürchtung ist, dass es sich hier um einen Kernel-Flashfehler handeln könnte. Vermutung: In den ersten Monaten hat der Kernel mit einem leeren Flash arbeiten können. Mittlerweile muss er Flashsektoren löschen bevor er schreibend darauf zugreifen kann. Gibt es Erfahrungswerte dazu?

Vielen Dank!



Systemkonfiguration:
Raspbian Stretch, aktueller Updatestand, Linux emibox0001 4.19.95-rt38-v7+ #1 SMP PREEMPT RT Tue, 16 Jun 2020 13:25:43 +0200 armv7l GNU/Linux

[dirk]

Hi energiemanagement, vielen Dank für Deine ausführliche Fehlerbeschreibung.
Erstmal ja es könnte ein eMMC Problem bestehen jedoch ist dies auch für uns eine Black-Box.
Um Schreibzugriffe zu vermeiden gibt es im WebStatus die Option "Store logs on: tmpfs-backed directory".
https://revolution.kunbus.de/tutorials/ ... r-stretch/

WebStatus

2020-09-21 15_14_54-.jpg (71.25 KiB) Viewed 5260 times

Dass die A1 und A2 LEDs grün leuchten ist seltsam. Dazu benötigen wir mehr Informationen.
Bitte erstelle und poste oder schicke uns einen sos-report:

Code: Select all

pi@RevPi40302:~ $ revpi-sos
The report will be generated under folder /tmp in a .tar.xz file, which
can be extracted with command: tar -Jxvf xxx.tar.xz in linux or 7zip in Windows.
And then some inspection can be done before it is sent to support@kunbus.com.
Are you going to continue (N/y)?y
report generating...

Your report has been generated and saved in:
/tmp/sosreport-RevPi40302-20200921152215.tar.xz

To make the report have better accessibility, the ownership of the report
can be changed to the current user.
Are you going to proceed(N/y)?y
The ownership of /tmp/sosreport-RevPi40302-20200921152215.tar.xz has been changed to user:pi

Um Dein eMMC auf Fehler zu prüfen kannst Du Dein eMMC via USB mounten und mit "fsck" die Root Partition prüfen.
Falls Du kein Linux System hast, kannst Du z.B. ein Live Ubuntu booten und usbboot installieren.

Code: Select all

# build rpiboot
sudo apt update
sudo apt install git
sudo apt install libusb-1.0-0-dev
git clone --depth=1 https://github.com/raspberrypi/usbboot
cd usbboot
make
sudo ./rpiboot

Weiterhin kannst Du folgendes tun, um zu prüfen, ob das eMMC fehlerhaft ist:
1) Generiere Dir eine Image Datei, die so groß ist wie notwendig.
Hier ein Beispiel wie ich es machen würde - ich habe einen USB Stick gemountet, auf den ich das Image schreibe

Code: Select all

pi@RevPi40302:~ $ sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 3.7 GiB, 3909091328 bytes, 7634944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcd48578f

Device         Boot Start     End Sectors  Size Id Type
/dev/mmcblk0p1       8192   96042   87851 42.9M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      98304 7634943 7536640  3.6G 83 Linux

pi@RevPi40302:~ $ dd if=/dev/zero of=/mnt/zero.img status=progress count=7634944

2) Schreibe diese Datei auf Dein Device
3) führe ein Power Cycle durch ohne zu Booten
4) Lese dieses Image vom Device
5) Vergleiche binär die Kopie und das Image - unter Windows z.B. mit

Code: Select all

fc /b <datei1> <datei2>

[energiemanagement]

Hallo Dirk,
vielen Dank für die vielen hilfreichen Informationen. Ich werde nun meine Logs mitschreiben und mich beim nächsten Mal mit hoffentlich ausführlichen und hilfreichen Logs melden. Das Flash zu checken werde ich auch bei nächster Gelegenheit mal durchführen. Derzeit läuft das Gerät zum Glück wieder durch.
Viele Grüße und ein schönes Wochenende,
Chris