Tank startet nicht aus dem Deep Standby

[Uli1101]

Hallo zusammen,
aus Energiespargründen setze ich meine Tank in den Deep Standby (DS). Beim Aufwecken bleibt sie so ca. jedes 5. Mal hängen und ist nur durch einen harten Neustart zum Arbeiten zu bewegen. Das gleiche passiert auch bei Aufnahmen aus dem DS. Die Anzeige im Box-Display zeigt dann jedes Mal "starting". Scheint irgendwas mit nicht verfügbarer Festplatte zu tun zu haben.
Ich nutze das Nightly vom 21.3.19. Der Fehler trat aber auch schon bei älteren Nightlys auf.
Wär schön, wenn sich jemand von den Tank-Cracks die Sache mal ansehen könnte. Danke schonmal für Eure Hilfe!!!
Grüße von Uli

In den angehängten Files zeigt sich der Fehler - oder korrekter Ablauf - jeweils ab Zeile 450:
Korrektes Aufwachen aus dem DS:

putty20190527182236 korrektes aufwachen aus deep standby.log

Korrektes Aufwachen aus dem DS. Fehler bei der FP-Einbindung.

(52.41 KiB) 149-mal heruntergeladen

Fehler bei Auwachen aus dem DS:

putty20190527182116 fehlerhafter start aus deep standby.log

Fehler bei Auwachen aus dem DS. Fehler bei der FP-Einbindung.

(22.43 KiB) 184-mal heruntergeladen

Das Problem scheint gelöst zu sein - zumindest eins... Ich habe die interne Spannungsversorgung der Platte auf dem Mainboard auf die andere Schnittstelle getauscht. Jetzt wird die Platte ordnungsgemäß eingebunden. Siehe log-File zwischen Zeilen 429 und 451.

[Uli1101]

Inzwischen habe ich auf Nightly 3.60 vom 28.05.2019 upgedatet. Problem tritt weiter auf.

Kann bitte jemand die beiden Files ansehen, einmal korrekter, einmal fehlerhafter Start. Beide Male wird die FP richtig eingebunden (Zeilen 429-455). Das Problem beginnt ab Zeile 466:

putty20190530195339 fehlerhafter manueller Start aus deep standby.log

Fehler bei Auwachen aus dem DS. Korrekte FP-Einbindung.

(23.14 KiB) 177-mal heruntergeladen

putty20190530195546 korrekter manueller Start aus deep standby.log

Korrektes Aufwachen aus dem DS. Korrekte FP-Einbindung

(45.64 KiB) 172-mal heruntergeladen

Hat da jemand noch ne Idee???? Danke!!!!

[jfk]

Hi Uli1101
ich wollte Dir sagen , dass ich gleiche Problem seit ca. 1.5 Jahr habe .
Zuerst habe gedacht , es liegt am NAND Speicher. (viele BAD Block)
Habe getauscht aber leider hat das nicht geholfen.
Ich gehe davon aus, dass hier ein thermisches Problem an BGA Speicher/CPU gibt (Kontaktprobleme Solder Ball ?).
Wenn man nach der fehlerhafter Start .. Tank ausschaltet und einschaltet ..bootet box ohne Probleme.

Mein log :

error_boot.log

(25.39 KiB) 190-mal heruntergeladen

[Uli1101]

Hi jfk,
danke für Deinen Input. Ich glaube nicht an ein thermische Problem, weil, wie Du auch sagst, die Box nach nem harten Reset sofort sauber startet - und zwar jedes Mal. Aber unsere Fehler (bei mir Zeile 466, bei Dir Zeile 485) sind wirklich identisch. Ich hoffe, daß jemand von den Image-Cracks hier eine Idee hat. Ich glaube wirklich an einen Bug im Image.
Grüße,
Uli

[jfk]

Seit wann hast Du Problem ?

[Uli1101]

Seit langem. Hatte das schon bei meiner Neo2.

[Uli1101]

Hallo,
weil der Absturz der Box an einem Punkt passiert, wo im nicht gestörten Fall die Abfrage der Uhrzeit über Netzwerk passiert, habe ich die Box mal vom Netzwerk getrennt und die Uhrzeit über Satellit bezogen. Folge: Gleich beim ersten Start aus dem Deep Standby bleibt die Box hängen. Ich habe diesen Start - natürlich - nicht mitgeloggt...
Wäre schön, wenn es ein core dump-fähiges Image geben würde.
Viele Grüße!

[jfk]

Ich glaube .. habe ich ende 2017 oder bisschen früher gemerkt.
Ich versuche herauszufinden wann Kernel-Versionen wechseln stattgefunden haben.
Es sieht nach einer Kernel-Bug aus.

[Uli1101]

Ja, den Verdacht hab ich auch.
Meinst Du, es macht Sinn, mal das letzte offizielle Image
https://neutrino-images.de/neutrino-images/release/
zu flashen und die jeweiligen SW-Stände zu vergleichen? Das Image ist 3.40 von Okt 17. Ich weiß aber nicht, ob das gefährlich ist und wir vielleicht nicht einfach zum 3.60 zurück kommen...
Ich könnte das morgen früh mal probieren.
Grüße!

[jfk]

nee .. es macht keinen Sinn letzte Image zu flashen.
Aber versuch mal mit 3.20 Version
https://neutrino-images.de/neutrino-ima ... 609282207/

Ich habe mir genau angeschaut.
Ich sehe warum crash..aber ursache kenne ich noch nicht.

Problem ist memory init ( cnxt_kal_internal_mem_init) in module LnKKALDrv.ko.
Dort ist Funktion "cnxt_heap_create" aufgerufen.

Dann cnxt_heap_create+0x48 haben wir Crash , weil R4 == NULL ist !

Weiß jemand was ist ""KALUNC1"" ?

[Uli1101]

Habe jetzt mal das Image 3.20 von 2016 geflashed. Dieses hat aber den gleichen Kernel 3.10.93, wie das aktuelle Image 3.60. Daher glaube ich nicht, daß unser Problem damit behoben ist. Aber wir werden sehen...

[Uli1101]

Das Log von einem korrekten Start aus dem Deep Standby mit Image 3.20

putty20190616195426 Image 3.20 Ok-Start aus deep standby.log

Korrekter Start aus dem Deep Standby mit Image 3.20.

(44.55 KiB) 174-mal heruntergeladen

zeigt bei Zeile 460 ein init mit "BusyBox v1.23.2" statt "BusyBox v1.30.1" aus dem Image 3.60

putty20190530195546 korrekter manueller Start aus deep standby.log

Korrekter Start aus dem Deep Standby mit Image 3.60.

(45.64 KiB) 178-mal heruntergeladen

. Bei Zeile 466 gibt es einen Unterschied zwischen Image 3.20 und 3.60. Das Problem hängt vielleicht wirklich mit der Routine zur Zeitsynchronisierung zusammen?

Gibt es noch jemanden von den Image-Spezialisten, der hier helfen kann???? Hilfe!!!!

[Don de Deckelwech]

Hi,
dann unter Einstellungen->Netzwerk->Zeit-Syncro auf DVB stellen, vllt ist dein Netzwerk einfach zu lahm (warum auch immer, dürfte nicht vorkommen!)...

Ciao,
DdD.

[jfk]

Ich habe Ntp Zeitsynchro beim booten über Menu ausgeschaltet . Seit 2 tagen kein Crash bei booten.
Nach paar Tagen kann man mehr sagen...

[Uli1101]

Da bin ich gespannt, wie das bei Dir weitergeht!

Ich habe mahrmals hin und her geflashed, 3.20, 3.40. Jetzt bin ich seit gestern auf 3.60.303. Habe einige Versuche gemacht, und bis jetzt läuft alles stabil. Mir ist auch aufgefallen, daß sich die 3 Versionen ziemlich unterschiedlich verhalten beim Beenden in den deep standby und auch beim Booten, wenn beim ersten Mal die Zeit über ntp synchronisiert wird.

Wir bleiben dran!

[Don de Deckelwech]

Hi,

Mir ist auch aufgefallen, daß sich die 3 Versionen ziemlich unterschiedlich verhalten beim Beenden in den deep standby und auch beim Booten, wenn beim ersten Mal die Zeit über ntp synchronisiert wird.

will das nicht in Frage stellen, aber kannst du das iwie darlegen? Was war da anders?

Ciao,
DdD.

[Miky]

Post 12 z. B.

[Uli1101]

Ich mach die Tage mal ein file mit den Unterschieden aus 3.20, 3.40 und 3.60.303. Vielleich kann DdD oder jfk was damit anfangen.

[Uli1101]

Im Moment läuft meine Tank mit dem 3.60.303 seit gestern morgen völlig problemlos.

Jetzt habe ich eine kleine Textdatei gebaut mit einem Vergleich "letzte Phase Start aus Deep Standby" und "letzte Phase Legen in den Deep Standby"
für die Images 3.20, 3.40 und 3.60.303

Vergleich verschiedener Images.txt

(9.15 KiB) 181-mal heruntergeladen

Beim Start fällt auf, daß nur bei 3.60.303 direkt nach der Netzwerkkonfigurierung der Abgleich mit dem Zeitserver passiert. Beim Runterfahren in den Deep Standby gibt es diverse Unterschiede, vor allem der Zeitpunkt, wann die Timer gesetzt werden und der Aufruf der Routine "shutdown_helper" als vorletzter Schritt beim 3.60.303.

Vielleicht habt Ihr dazu eine Idee. Danke!

Grüße von Uli

[jfk]

Heute bei booten stand auf "starting .." Habe nicht geloggt.

Edit :

Ich glaube wir können der Fehler eingrenzen:
In OK log steht:

Jan 01 00:00:14 TankWohnzimmer user.info networking[597]: Configuring network ...

in Errorlog haben wir Kernel "Debug" ohne string " Configuring network ... "

Ich glaube es liegt nicht an Zeit Synchro.. man sieht in log doch die Zeit Jan 01 00:00:14.

In etc/init.d ..Bootdatei rcS haben wir:

# set dummy time
date -s "2017-01-01 00:00"

..
..
service hostname start

-------------
In hostname wird Netzwerk konfiuriert:

hwaddr=$(ifconfig eth0 | awk '/HWaddr/ { split($5,v,":"); print v[4] v[5] v[6] }')

Ist "ifconfig" Kernelbefehl ? oder BusyBox ?