Green-LED-Blinking PowerOff Bug

  • ab und zu bleibt ein power-off beim runterfahren mit gruen blinkender led haengen. der einzige ausweg ist dann ein manuelles poweroff/on an der box.

    der bug laesst sich mit einer reboot-loop reproduzieren, z.b. durch folgende befehle in der /etc/rc.local

    Code
    sleep 60s # damit man nach dem booten zeit hat, die reboot-loop abzuschalten
    systemctl reboot ....

    hab mit der reboot version des shutdown befehls aus der /usr/bin/enigma2-system-state begonnen:

    Code
    systemctl --no-block reboot

    der hang tritt so nach 50-100 reboots auf

    Code
    systemctl reboot

    hang nach 50-100 reboots

    Code
    systemctl --force reboot

    hang

    Code
    systemctl --force --force reboot

    kein hang nach ca. 200 reboots.

    allerdings ist die letzte version ein ziemlich harter shutdown und es werden auch z.b. keine filesysteme unmounted.

    hab aber meinen usb-stick und sd-karte mit e2fsck gecheckt und keine filesystem-fehler feststellen koennen.

    von daher verwende ich jetzt erstmal in der /usr/bin/enigma2-system-state

    Code
    systemctl --force --force poweroff

    zum ausschalten, um weitere erfahrungen zu sammeln.

    letztendlich sollte aber der bug von dream behoben werden, ich halte ihn fuer einen showstopper fuer eine wohnzimmer-box.

  • Exactly my sentiments… DP should test their new boxes prior to shipping them. Now the buyers are their guinea-pigs.. Far too many (hidden) bugs in the Dream-One and Dream-Two.. Luckily for them the user-community is so strong and willing… But in fact it’s a shame for those prices…

    And DP, please, please step into the 21st century and abondon those ANCIENT skins!!! Boxes have a lot of memory nowadays.. Do something about it…

  • Ich bin auch bei Apple und Microsoft ein Tester. Finde dich damit ab. Grad bei allem, was mit systemd zusammenhängt, kannst du mit einer Änderung vieles kaputt machen.


    Du kannst z.B. auch das ZapStatistic Plugin installieren. Das gibt beim shutdown zuverlässig einen stack trace.


    Es gibt nicht den einem shutdown. Das ist ein komplexes Zusammenspiel verschiedener systemd services und manch einer wird dann noch mit alten init.d reinfunken.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • habe noch ein bisschen gelesen und 2 befehle gefunden, die die gefahr von datenverlust vermeiden sollten:

    - sync: schreibt die i/o buffer auf die devices

    - echo u > /proc/sysrq-trigger: mounted alle filesysteme read-only

    Code
    sync
    echo u > /proc/sysrq-trigger
    systemctl --force --force poweroff

    nochmal: das ganze ist als workaround gedacht, bis dream den bug gefixt hat.

  • I am the worst skinner and developer so i restart reboot my boxes up to 100 times a day when i work at something and have never hade any data lost or strange light blinking.

    I practical abuse my dreamboxes with bad programming and skinning so this "bug" must be very rare??


    Also all my boxes is set to go into deep standby after idle for 3 hours and they all start just perfect with the remote or button press.

    Everything in life that's any fun is either immoral, illegal or fattening

  • Hallo alpha,


    bin mal gespannt auf Deine Langzeiterfahrung mit deinem Patch.

    Schöner wäre natürlich ein offizieller Bugfix von DP.

    Nach der Meldung des Shutdown crashs an DP vor ca. einem 1/2 Jahre, habe ich nur die Rückmeldung

    erhalten, dass diese an die Entwickler weitergeleitet wurde. Passiert ist aber nichts. Der Bug ist auch

    noch in der neusten FW Version der ONE und TWO enthalten.


    Wenn Du willst, kannst Du Deinen Fix ja mal unter Realbedingungen weiter testen:


    Das anhängende Script: "timers.py" das man auf der ONE laufen lassen kann und das eine "etc/enigma2/timers.xml"

    erstellt, löst einen wiederkehren Programmwechsel und Neustart der Box per Timer aus.


    Diese timers.py muss man aber in Punkto "ServiceRef" evt. anpassen.


    timer.py erwartet, dass man in


    /usr/lib/enigma2/python/mytest.py


    die Timer Hochlaufzeit verkürzt.


    Wenn man dies nicht will kann man in timer.py das Delay2 auf 270 Sekunden vergrößern.

    Hat dann aber weniger Tests / Zeiteinheit.


    Bin mal gespannt auf die Ergebnisse. Vielleicht kann ich ja dann bereits wieder auf die Nanny verzichten!

    Wäre natürlich Schade um die viele Arbeit die ich mit Ihr hatte!


    /Willi/

  • alpha : hm, bin mir nicht sicher, ob es sinnvoll ist, alles read only zu setzen. Da musst du dir ganz sicher sein, dass alles, was noch irgendwas schreiben will, damit auch wirklich fertig ist.


    Schnubbel : was genau sollte denn deiner Meinung nach hier aufgeräumt werden? Ich sehe hier keinerlei Verwendung eines binaries von gutemine

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • alpha : hm, bin mir nicht sicher, ob es sinnvoll ist, alles read only zu setzen. Da musst du dir ganz sicher sein, dass alles, was noch irgendwas schreiben will, damit auch wirklich fertig ist.

    meine annahme war, dass wenn enigma2 beendet ist, ein sync gemacht ist, nichts mehr geschrieben werden muss. aber ja, muss man schauen...

  • Hallo Alpha,


    Schaut man sich mal das Dreambox LOG an:


    Hier eine Kopie aus dem Thread: "Eine Nanny für die ONE und TWO":


    [ 102.882849@2] fb: osd_shutdown

    [ 102.883215@2] amvdac_drv_shutdown: shutdown module, private_flag:0x0

    [ 102.883986@0] reboot: Power down

    [ 102.884280@0] fp_power_off

    [ 102.987219@0] fp_write_cmd(33) timeout...

    [ 102.987241@0] fp: com reset...

    [ 103.007767@0] fp: command retry

    [ 120.171199@0]

    [ 120.171199@0]

    [ 120.171199@0]

    [ 120.171199@0] HARDLOCKUP____ERR.CPU[1] <irqen:0 isren1>START

    [ 120.171780@0]

    [ 120.171780@0] dump_cpu[0] irq: 3 preempt:10001 swapper/0

    [ 120.172606@0] IRQ arch_timer_handler_phys, 10000

    [ 120.173129@0] Task dump for CPU 0:

    [ 120.173520@0] swapper/0 R running task 0 0 0 0x00000000

    [ 120.174349@0] Call trace:

    [ 120.174654@0] [ffffffc0746f1c40+ 112][<ffffff800908b688>] dump_backtrace+0x0/0x250

    [ 120.175521@0] [ffffffc0746f1cb0+ 32][<ffffff800908b95c>] show_stack+0x24/0x30

    [ 120.176352@0] [ffffffc0746f1cd0+ 32][<ffffff80090dce9c>] sched_show_task+0x134/0x180

    [ 120.177251@0] [ffffffc0746f1cf0+ 32][<ffffff80090dfc48>] dump_cpu_task+0x48/0x58

    [ 120.178113@0] [ffffffc0746f1d10+ 112][<ffffff8009b6c50c>] pr_lockup_info+0x174/0x220


    Dann sieht man folgendes:


    Der Frontprozessor der Box macht das Powermanagment. Er kann dem Hauptprozessor

    die Stromzufuhr kappen und per Timer oder IR Befehl wiedergeben.


    Als welchen Gründen auch immer verliert der Hauptprozessor manchmal den Kommunikations-

    weg zum Frontprozessor:


    Siehe hier:


    [ 102.882849@2] fb: osd_shutdown

    [ 102.883215@2] amvdac_drv_shutdown: shutdown module, private_flag:0x0

    [ 102.883986@0] reboot: Power down

    [ 102.884280@0] fp_power_off

    [ 102.987219@0] fp_write_cmd(33) timeout...

    [ 102.987241@0] fp: com reset...

    [ 103.007767@0] fp: command retry


    Der Hauptprozessor sagt zum Frontprozessor: "Power_off", aber der hört's nicht!


    Erst danach erfolgt der Crash.


    Das lässt sich über Dein --forced Shutdown wahrscheinlich nicht umgehen. Das Hängelbleiben

    beim Runterfahren wird wohl bleiben.


    Schaut man sich die Dreambox LOGs mal näher an. (ich habe die mal über mehrere Monate

    gemacht), dann fällt auf, dass die Kommunikations zum Frontprozessor nicht nur beim "power_off"

    hakt sondern auch wenn eine neue Aufweckzeit in diesen geschrieben werden muss. Machmal

    klappt es durch ein Retry aber auch nicht immer.


    Das kommt zwar wirklich selten vor, aber zu 100% funktioniert die Kommunikation zwischen den

    beiden eben nicht.


    Da einige davon berichten, dass der Shutdown Fehler bei Ihnen noch nie aufgetreten ist, kann

    es auch ein HW Fehler sein.


    Ich habe inzwischen 6 Boxen vom typ ONE ausprobiert und eine TWO. Bei allen ist der Shutdown

    Fehler aufgetreten.


    Meine Nanny wird wohl auch weiterhin einen Job haben.


    /Willi/

  • ja, vermutlich wirst du deine nanny weiter brauchen :frowning_face:

    musste erstmal wieder die beiden befehle "sync" und "echo u > /proc/sysrq-trigger" rausnehmen, weil damit nach nur kurzer zeit hangs auftraten.

    nur mit "systemctl --force --force poweroff" lief die timerloop dann mit Delay2=90 von 23:00 bis 4:00... also ca. 200 reboots und hing dann mit blinking green light.

    ob die fp-kommunikation etwas damit zu tun hat, weiss ich nicht. muesste dann nicht das setzen der aufwachzeit manchmal schiefgehen und die box nicht aus dem poweroff aufwachen? sowas habe ich bisher nicht beobachtet.

  • so, ich habe nochmal etwas nachgeschaerft und verwende jetzt statt "systemctl --force --force poweroff" "echo o > /proc/sysrq-trigger".

    damit lief eine vereinfachte version der timerliste von willi.neu9 (ein umschaltimer alle 90s mit standby) von 13:00 bis 23:00 ohne hang und ohne filesystem fehler durch.

    damit habe ich erstmal fertig.


    enigma2-system-state.txt

    3 Mal editiert, zuletzt von alpha ()

  • Hallo Alpha,


    nur zu meinem Verständnis:


    Code
    "system-standby")
    echo "powering off..." >> /data/log.txt
    #			systemctl --no-block poweroff
    #			systemctl --force --force poweroff
    echo o > /proc/sysrq-trigger
    ;;

    Waren bei Deinem letzten Test:


    # systemctl --no-block poweroff

    # systemctl --force --force poweroff


    auskommentiert?


    Und zur Befriedigung meiner Neugierde:


    Wie bist Du auf den Befehl gekommen:


    Code
    echo o > /proc/sysrq-trigger


    Die anderen möglichen Befehle konnte ich dann durch die Eingabe von:


    echo a > /proc/sysrq-trigger


    rausfinden. Die Ausgabe erfolgte am USB Service Ausgang der Box:


    SysRq : HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m)

    nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) show-blocked-tasks(w) dis intr to riggger wdt rst(x) dump-ftrace-buffer(z)


    /Willi/

  • willi.neu9:

    - ja, die beiden befehle systemctl... waren beim test auskommentiert.

    - auf den echo befehl bin ich durch googeln nach shutdown-befehlen, wenn das system haengt, gekommen. wenn ich es richtig verstehe, dann triggert der befehl direkt den kernel, ein power-off zu machen.... umgeht also systemd, das vermutlich fuer die hangs verantwortlich ist.

    Einmal editiert, zuletzt von alpha ()

  • alpha


    systemctl ist wahrscheinlich nicht der Schuldige. Denn die LOG Meldung "fp_power_off" kommt aus

    den Kernelmodul "/lib/modules/4.9/extra/fp/fp-dev.ko", dass auch aufgerufen wird wenn man ein

    "echo o > /proc/sysrq-trigger" ausgibt. Das ist genau das was systemctl auch erfolgreich macht,

    sonst käme die Meldung "fp_power_off" nicht vor dem Crash.

    Ich vermute mehr ein Kommunikationsproblem zwischen dem Kernelmodul und dem Frontprozessor.

    Ist aber auch von meiner Seite nur eine Spekulation, da auch schon vorher im Main System irgendwas

    passiert sein kann, was dazu führt, dass das Kernel Modul nicht mehr richtig funktioniert.


    /Willi/

  • dass bei der fp-kommunikation retries auftreten, scheint normal zu sein. ich hab hier auch bei funktionierenden poweroffs retries gesehen.

    denke aber, dass das nur die experten von dream beantworten koennen... wenn sie denn wollten :winking_face:

    Einmal editiert, zuletzt von alpha ()