Neutrino-Images

Hi,
thx, ich mach mich dran, kann aber bis morgen dauern.

Ciao,
DdD.

Hi,
hier die geänderte rcS. Wie gesagt: .txt entfernen, FTP-Transfermodus auf Binär stellen und nach dem Kopieren unbedingt auf die Ausführungsrechte 755 achten!
Tja, und dann brauchen wir wohl Geduld, bis der Fehler wieder auftritt und du das mitloggen kannst...

Ciao,
DdD.

Vielen Dank!

Die neue rcS läuft. Jetzt Geduld haben und jeden Start mitloggen...

Heute habe ich verpasst zu loggen
Über eine Woche bis Heute ist ohne Probleme gelaufen. Image 3.60.332 25.06.2019.

Ich werde jetzt loggen auf Raspberry Pi umleiten. Dann verpasse ich nicht.

Aber heute ist Deine Tank abgestürzt? Verwendest Du die geänderte rcS-Datei? Du hast mit dem pi bessere technische Möglichkeiten als ich. Viel Erfolg!!! Ich bin gespannt!

Bei mir läuft alles seit ein paar Tagen ok. Mit 3.60.303

Uli1101 hat geschrieben: ↑Sa 6. Jul 2019, 14:28 Aber heute ist Deine Tank abgestürzt? Verwendest Du die geänderte rcS-Datei? Du hast mit dem pi bessere technische Möglichkeiten als ich. Viel Erfolg!!! Ich bin gespannt!

Bei mir läuft alles seit ein paar Tagen ok. Mit 3.60.303

Ja , Heute ist meine Tank abgestürzt. (Aber nicht mitgeloggt)
Ja , ich habe rcS-Datei geändert.

So, jetzt hab ich ihn: Der gleiche Fehler im gleichen Modul auch schon Ende Mai: Segmentation-Fehler bei der Initialisierung "init of module lnxKKALDrv" in Zeile 495 bzw. 466. D.h. auch, wir können wieder zu der alten rcS ohne Ausgaben zurück.

Was mir noch auffällt: Zeile 42 "Warning - bad CRC or SFC, using default environment". Deutet das auf einen internen Speicherfehler, Hardwarethema? Hat jfk auch sowas?

Könnt Ihr damit was anfangen? Können wir evtl. in dem Modul "lnxKKALDrv" eigene Diagnoseausgaben setzen?

Viele Grüße!

Vermutlich eine race condition beim laden der Module. Da wohl ein CST Modul betroffen ist, wird da nichtmal viel bei rumkommen wenn man den Crash in einem Debug Image nachstellt. Probieren könnte man aber...

Hat jemand lnxKKALDrv Modul aus 2.6.34.14 und kann hier posten ?

In 3.10.93 habe ich gesehen, dass bei Init ioremap umgegangen werden kann.
Bei Crash ist "ioremap " umgegangen und an die Funktion "cnxt_heap_create" Adresse = NULL übergeben ist.

Dann kann ich beide vergleichen.

gandharva hat geschrieben: ↑Mo 8. Jul 2019, 10:48 Vermutlich eine race condition beim laden der Module. Da wohl ein CST Modul betroffen ist, wird da nichtmal viel bei rumkommen wenn man den Crash in einem Debug Image nachstellt. Probieren könnte man aber...

Hallo, ich mal wieder mit dem alten Fehler. Ich hab jetzt das debug-Image installiert, hatte aber einen Fehler in der .coredump, sodaß ich keinen coredump aufgezeichnet habe. Aber ich habe mitgeloggt, während die Box "starting..." anzeigte Vielleicht kann damit jemand was anfangen. Danke schonmal und viele Grüße!
Uli

Abgesehen davon, dass da wohl ein Problem mit dem laden eines Modules ist: hat die Festplatte wohl auch ein Problem

Die Datenträgerüberprüfung ergibt keinen Fehler. Hmmm...