Eine Nanny für die ONE und TWO - oder der steinige Weg zur grünen Box

  • Die Dreambox ONE oder TWO bei nicht Gebrauch in den Standby Modus zu setzten bringt in Punkto Stromverbrauch fast nichts.

    Dieser verringert sich dabei lediglich um ca. 10% (gemessen direkt an der Box). Da ist der Deep Standby Modus bei dem der

    Hauptprozessor inklusive USB Peripehrie komplett abgeschaltet wird schon wesentlich effizienter. Hier beträgt die Strom-

    ersparnis schon mehr als 99%. Die Stromaufnahme sinkt von ca. 600 mA bei 12 Volt auf etwa 3 mA.


    Leider kann man sich nicht darauf verlassen, dass ein Deep Standby bei der ONE oder TWO immer funktioniert. Egal ob dieser per

    Fernbedienung oder per Timer ausgelöst wurde. Bei gefühlt jedem 50 Shutdown bleibt die Box bei runterfahren (wie auch DP bereits

    vor ca. einem halben Jahr mitgeteilt) hängen.


    Bug inzwischen durch DP gefixt? -> NO!! (Seufz)


    Ein LOG genommen vom USB-Service Ausgang der Box zeigt den Grund:


    [ 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


    Um Die Box aus dem Crash Zustand zu befreien hilft nur noch: Strom abschalten, für ca. 3 Sekunden zu warten und danach die Box

    wieder einzuschalten.


    Da ich nicht davon ausgehe, dass dieser Fehler jemals gefixt wird, und ich auch nicht auf Dauer die Nanny für die Box sein möchte,

    habe ich der ONE eine Nanny gebaut, (wäre für die TWO übrigens auch nötig) die auf die Box aufpasst.


    Diese wird einfach zwischen Netzteil und Box gesteckt und unterbricht bei Bedarf die Stromzufuhr zur Box für ca. 3 Sekunden und

    startet damit die Box automatisch neu. Nach ca. 30 Sekunden schickt sie per IR das Abschaltkommando zur Box um diese wie ge-

    wünscht dann doch noch runterzufahren.


    Sie funktioniert dabei wie folgt:


    Beim Runterfahren blinkt die LED im Ein/Aus Taster der Box mit ca. 0,93 Hz so lange bis diese abgeschaltet ist. Bleibt der Abschalt-

    vorgang hängen blinkt die LED bis zur Stromtrennung kontinuierlich weiter.


    Dieses Blinken lässt auch die Stromaufnahme der Box zyklisch schwanken. Mit einem 0,93 Hz Filter in der Nanny wird die Strom-

    schwankung ausgefiltert und dem A/D Wandler eines Microcontrollers in der Nanny zugeführt. Dieser schaut sich das Blinken für ca.

    1 Minute lang an. Danach startet er den Zyklus:


    Stromzufuhr zur Box für 3 Sekunden trennen.

    IR Kommando: Runterfahren nach 30 Sekunden Wartezeit senden.


    Das ist schon sein ganzer Job.


    Wen die Nanny interessiert: Nähere Infos (Stromlauf / Firmware / Fotos) gibt es hier:


    nanny_1.00.zip


    Hier noch ein paar Bilder:


            


    /Willi/

    Einmal editiert, zuletzt von willi.neu9 ()

  • Du kannst ein ähnliches Verhalten ganz leicht selbst und immer verursachen indem du den halt Befehl in telnet/shh eingibst.


    Probiers "halt" mal aus und berichte ob deine Vorrichtung dann auch anspringt.


    PS: Wobei ich im BA dafür einen Workaround eingebaut habe um die box immer rebooten zu können und nicht in so einem Zustand hängen zu bleiben. - mir ging es dabei aber nicht ums Stromsparen :smiling_face_with_sunglasses:

  • dann hoffen wir mal, dass dieser bug bei der seven gefixt ist, sonst waere das fuer mich ein nogo.

    bei der one ist mir der fehler auch schon negativ aufgefallen, aber da die box nicht in production ist, kann ich ihn verschmerzen.

  • Ich denke das ist eigentlich kein "bug", sondern hängt damit zusammen das die one/two so flott sind und mehr cores als die anderen Boxen haben und das systemd-shutdown dann schon reboot aufruft wenn noch andere Sachen laufen - die dann halt crashen weil noch nicht fertig. Deswegen tritt es beim halt auch "immer" auf und sonst "gelegentlich"


    Und genau das ist auch relativ leicht zu verhindern ... aber genau deswegen frage ich ja ob Ihr das verifizieren könnt .... weil ich bin aus dem Alter für Nannies schon raus :winking_face_with_tongue:

  • Ihr müsst nicht alles wissen ... es hat ja einen (beziehungsweise eigentlich mehrere) Grund warum meine "speziellen Freunde" es nach so vielen Jahren noch immer nicht geschafft haben mein bainit binary vom BA fürs DreamOS nachzubauen. Das sind halt meine kleinen Geheimnisse :thinking_face:


    Außerdem will ich mich nicht wichtig machen solange ich nicht weis ob willi wirklich vom gleichen Problem redet, ich habe die Bootlogs von damals schon längst vergessen.... es sieht nur seeeehr bekannt für mich aus ....


    Wenn Ihr es testen wollt kann ich den Code Teil aber in ein kleines standalone Binary rausschneiden mit dem kannst du dann die box 100x rebooten ohne das dir die box hängenbleibt, weil genau so habe ich das damals auch getestet wie die one rauskahm und BA dann dieses Problem beim Rebooten in "speziellen Fällen" hatte. Und ja, wenn meine kleine Anpassung beim Reboot funktioniert denke ich schon das es auch beim Box anhalten den gleichen Effekt haben sollte.

  • Jetzt schaut erstmal mit dem halt Befehl nach ob ich damit recht habe .... ich musste das damals ja auch einfach reproduzierbar machen ...


    Und bitte kein halt eingeben wenn die Harddisk grade für eine Aufnahme läuft, außer Ihr steht auf Filesystemchecks. Am besten wenn am USB einfach abstecken ...

  • Das weis ich doch, es geht um das console log ... ob du im wesentlichen Ähnliches drinnen steht ... und es wird bei 100x halt auch nichts anderes sein :face_with_open_mouth:


    Weil ich mag solche Aussagen wie bugs die wohl nie gefixed werden NICHT, weil ich eben denke das es eigentlich kein bug ist sondern ein durchaus lösbares Problem - auch ohne was zu Löten :winking_face:


    Man muss nur versuchen es zu verstehen ... mir blieb damals ja auch nichts anderes über ... selbst wenn es was anderes ist ...

  • Immer sollen die anderen was Arbeiten :tired_face:


    Aber egal, im Anhang ist das gReboot binary zum Vergleichen mit dem normalen halt.


    Das kannst du nach dem Installieren des deb auf der one/two mit gReboot in gtelnet/ssh aufrufen um die box hart zu rebooten und mit gReboot -h macht sie ein Halt, das eben im Unterschied zum normalen halt "crashfrei" von statten gehen sollte und wo du die box dann auch problemlos mit der FB wieder aufwecken können solltest.


    Damit sollte man eigentlich meine Vermutung verifizieren können. ob es das Gleiche und eben "lösbare" Problem ist.


    Und JA jetzt dürft zur Abwechslung mal IHR 100x Halt und Reboot machen, um sicher zu sein das es damit nicht passiert :fearful_face: aber wie gesagt .... besser ohne Harddisk ...


    Und NEIN. für was anderes ist das Binary eigentlich NICHT zu gebrauchen ....


    EDIT: Kit entfernt, weil die Leute das "für was anderes ist das Binary eigentlich NICHT zu gebrauchen" scheinbar immer noch falsch verstehen und glauben das man damit das Problem lösen kann.

    4 Mal editiert, zuletzt von gutemine ()

  • also prinzipiell funktioniert es.

    werde mal eine boot-schleife bauen, in der am ende vom booten gReboot aufgerufen wird.

    wo wuerde man es denn beim normalen ausschalten einbauen?

  • Das binary? Nirgends


    Wo der Code reingehört habe ich doch schon oben geschrieben...


    Und danke fürs testen...


    Wobei jeder derBA auf der one/two verwendet hat das dann bereits die letzten Jahre getestet.

  • Heißt also, wer bereits BA installiert hatte, hatte das Problem nicht ?

    Denn ein Hängenbleiben habe ich hier auf der One beim Shutdown noch nie bemerkt.

    Und meine Box geht jede Nacht per Elektro-Plugin in den DeepStandby.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Jein, weil wie gesagt beim bainit liegt der Focus auf sauberem rebooten und eben nicht auf sauberes runterfahren, das ist nur ein möglicher Nebeneffekt den ich aber nie aktiv untersucht bzw. getestet habe.


    Durch die lange Verwendung im BA kann ich aber ziemlich sicher sagen daß es keinen negativen Effekt hat.

    Einmal editiert, zuletzt von gutemine ()

  • Also um die Sache nicht unnötig in die Länge zu ziehen, habe ich ... für den Fall das ich möglicherweise Recht habe ... im aktuellen git des systemd einfach in den sourcen nachgesehen .


    im Prinzip beinhaltet ein aktueller systemd in etwas veränderter Form meine kleinen Codeanpassungen bereits und es gibt auch entsprechende backports bis zu stretch runter.


    Ich verstehe daher zwar das willi das Problem halt auf seine Weise angegangen und für sich auch "gelöst" hat, bei Aussagen wie 'wird wohl nie gefixed werden' wäre ich aber etwas vorsichtig, gerade wenn der code dafür schon seit Jahren im systemd git ist und halt nur gepushed werden muss.


    Wir verwenden halt systemd 232 was nicht gerade das aktuellste ist, auch wenn es derzeit noch so im OE2.6 ist (das OE2.5 hat noch 230)


    Die aktuelle Version vom systemd im bullseye ist hingegen 247, aber der entsprechende code ist z.B. auch schon im backport fürs stretch mit 241 drinnen.


    LG

    gutemine

  • Wo der Code reingehört habe ich doch schon oben geschrieben...

    dann habe ich es ueberlesen oder nicht verstanden.

    dachte, das binary war als circumvention fuer den shutdown-hang-bug gedacht. von daher muesste es doch irgendwo beim shutdown, nachdem sich e2 beendet hat (statt dem normalen halt???) eingebaut werden.

  • Nochmals NEIN, das binary ist NUR dafür da um zu verifizieren das es das Gleiche Problem ist bzw. das man es mit den entsprechenden code Anpassungen ganz leicht verhindern kann. Insofern baut man das eben NIRGENDS ein !!!


    Aber wenn da schon wieder urbane Legenden entstehen oder die Leute damit Blödsinn machen habe ich das deb zum Verifizieren sicherheitshalber entfernt und verweise NUR mehr auf meinen vorherigen Post das wahrscheinlich ein simpler push unserer systemd Version im OE 2.6 ausreichen würde, dass das Problem gar nicht mehr auftritt.


    Und NEIN ich fange jetzt sicher NICHT an für Euch am systemd herum zu patchen :nauseated_face:

    3 Mal editiert, zuletzt von gutemine ()