Jetzt versuche ich hier nochmal mein Glück.
Mein FHEM läuft seit langem nun auf einem Cubietruck. Es läuft eigentlich auch alles stabil. Nebenher läuft lediglich noch TV-Headend und seit einigen Zeit wieder minidlna. Die Stromversorgung läuft über das normale Netzkabel, zudem hat er noch einen LiPo als Notsromversorgung. Ganz selten kam es mal vor, dass ich nicht mehr zugreifen kann, und weil keine Tastatur und Monitor angeschlossen sind, bleibt dann nur ein Reset.
Jetzt hat es sich in den letzten Wochen aber stark gehäuft, ab und zu sogar öfters pro Woche. In der Syslog kann ich absolut nichts verdächtiges erkennen. Im Regelfall ist es sogar so, dass vor dem Ende längere Zeit gar nichts eingetragen wird. Das kann ich erkennen, wenn die Logs aus FHEM deutlich weiter gehen. Die Stromversorgung, die ich eigentlich erst im Verdacht hätte, glaube ich ausschließen zu können, da ich den Stecker ziehen kann und der Akku reicht dann noch für längere Zeit zu überbrücken. Auch sysmon zeigt nichts, was auf außergewöhnliche Belastung zeigt.
Es läuft Igors Image (Kernel 3.4.107) auf einer SSD.
Hat jemand einen Dunst, wo ich ausserhalb der Syslog noch informtionen finden kann? Oder hat jemand gar einen Tipp, wo die Ursache liegen kann? Kann es minidlna sein? Das macht doch bei mir praktisch fast nie was, es überwacht nur die Videos auf dem NAS, weil der TV diese nicht von dort spielen kann und deshalb das über den Cubie mit minidlna läuft. Allerdings ist es nie so gewesen, dass der Cubie hängt, während etwas darüber abgespielt wird.
ich hatte einmal das Problem, dass der MessageBus im Cubietruck sich total aufgehangen hatte. Strom raus und wieder rein --> alles gut
und dann hatte ich eine defekte SSD wo das SATA Interface abgefackelt war.
In beiden Fällen kamen die tollsten Dinge auf dem Bildschirm - aber auch nicht mehr im Syslog
Hmmm - besten Dank. Wie kann ich einen Fehler in der Platte erkennen? Es wird bei jedem Boot mittels Eintrag in /etc/default/rcS das Filesystem repariert werden. In /lost+found landet aber nichts.
Es gab da mal einen Thread, wo sich andeutete, dass das evtl. mit der CPU-Frequenz zu tun hat.
Beim Igor-Image wird wohl out-of-the-box etwas übertaktet, was nicht alle Boards gleichermaßen problemlos verkraften.
https://forum.fhem.de/index.php/topic,26992.0.html
Hatte ich gleich zu Anfang zurückgenommen. Jetzt habe ich jeglicher Logik zum Trotz doch erst mal einfach minidlna deinstalliert. Das war nunmal das letzte, was installiert wurde.
https://forum.fhem.de/index.php/topic,39880.0.html (https://forum.fhem.de/index.php/topic,39880.0.html)
Hatte ich auch schon.
Keine Ahnung woran es lag.
Ich hab dann auf einen anderen Cubie gewechselt und der läuft mit genau der selben Installation seither einwandfrei durch.
Ja, es muss Unterschiede in der Installation geben, aber ich hab dann nichtmehr weiter geforscht weil mir das dann irgendwann zu mühsam würde.
Edith: Die Neustarts kamen durch den watchdog (dafür ist er ja gedacht) - aber warum der zugeschlagen hat weiß ich nicht.
Edith1: Und ich hab an meinem Cubie auch einen Akku hängen.
Das mit diesem Watchdog muss ich mir mal ansehen. Zumindest fühle ich mich mit meinem Problem nicht mehr allein. Ein anderer Cubie währe ja auch nicht die Welt, allerdings stellt sich dann erst mal die Frage, ob der noch zeitgemäß wäre.
Jetzt will ich aber erst mal ein paar Tage sehen, wenn ich minidlna weg hab. Interessant: Habe den gerade mal testweise auf dem Raspie 3 installiert. Lief scheinbar ganz gut los - und nach einiger Zeit konnte ich nicht mehr zugreifen. Muss ich jetzt nicht verstehen, aber könnte ich als Indiz sehen, dass der das ganze sowohl auf dem Cubie als auch auf dem Raspi stört.
So, jetzt habe ich auch mal den watchdog eingerichtet und hoffe, dass der dann seinen Dienst erfüllt. Offensichtlich bin ich mit meinem Problem entgegen meinen Erwartungen irgendwie doch in "guter Gemeinschaft".
Habe dasselbe Problem, wo finde ich die Seite wie ich den watchdog aktiviere?
Funktioniert der auch wenn das ganze Betriebssystem abgestürzt ist bzw der Cubie "steht"?
Infos findest Du in dem von Puschel74 genannten Thread sowie dem darin angegeben Thread.
Die Beschreibung von Betateilchen findest Du einfach durch googeln nach "betateilche" und "watchdog" hier:
https://wiki.betateilchen.de/doku.php?id=raspberrypi:tec:watchdog
hmm, problem...
modprobe bcm2708_wdog
modprobe: FATAL: Module bcm2708_wdog not found.
Edit: warscheinlich heißt das Modul beim Cubietruck anders...??
Das wiederum steht in einem der erwähnten Threads:
Das Igor-Image hat die watchdog-device bereits eingebaut, deshalb ist dieser Schritt da nicht nötig. Du kannst das finden, wenn Du Dir den Inhalt von /dev auflisten lässt.
hmm, naja... in dem Image mit 3.4.109-sunxi ist das sunxi_wdt enthalten, von der Igor seite gibts ein Kernel update script um auf den Kernel 3.4.112-sun7i zu kommen, der hat das Modul leider nicht :(
Ich war auch betroffen.
Bei mir half das runtertakten und seitdem (2.Monate) keine Probs mehr (zuvor jeden Monat).
Ja, leider der Hardware-Watchdog ist nicht in allen Images verfügbar.
Um's auch hier noch abzurunden:
Der watchdog funktioniert. Ist einerseit gut zu wissen, andererseits zeigt es, dass minidlna nicht der Grund war. Erst lief der Cubie nun zioemlich genau 7 Tage, dann 14 Stunden.
Ich werde das wohl so auf weiteres erst mal akzeptieren, da ganz andere Kapazitäten als ich dem Problem offensichtlich hilflos gegenüber stehen. Immerhin läuft er ja jetzt erst mal wieder an und steht nicht.
Besten Dank nochmal für die Tipps.
Weiß das jemand: Hat der Vanilla-Kernel den Watchdog integriert?
Zitat von: Raven am 17 Juni 2016, 12:23:37
Ich war auch betroffen.
Bei mir half das runtertakten und seitdem (2.Monate) keine Probs mehr (zuvor jeden Monat).
Ja, leider der Hardware-Watchdog ist nicht in allen Images verfügbar.
Und nachinstallieren geht nicht?
Zitat von: duke-f am 11 Juli 2016, 11:24:35
Und nachinstallieren geht nicht?
http://forum.armbian.com/index.php/topic/211-kernel-update-procedure-has-been-changed/?p=11132
... back to the roots, kann man da sagen. Hätte ich auch selber drauf kommen können. Schließlich hatte ich ja auch meine positiven Erfahrungen mit Igor bezüglich Rückfragen.
Danke für den Tipp.
Danke auch von meiner Seite!
mmhhh...ggf. führe ich den Kernel-Upgrade durch, obwohl mein System nach begrenzen der CPU-Taktfrequenz nun stabil läuft.
Allerdings hat mein Cubie nun in der Sommerzeit im Hinblick auf Heizungssteuerung auch weniger zu tun.
Meine Heizungssteuerung läuft über USB und nicht auszuschliessen, daß dies die Ursache für die Abstürze war.
@Tobias:
Eine Frage habe ich die ganze Zeit immer wieder vergessen: Habe ich das richtig verstanden, dass Du das Problem auch beim Kernel 3.4.112 hast? Dann kann ich mir den Versuch eines Upgrades ja eigentlich sparen. Hab das am WE zwar mal kurz versucht, bin aber doch wieder zurück auf 3.4.107, weil ich den Watchdog vermisst habe.
Bei mir kommt mir das komisch vor, weil sich das Problem so akut erst die letzten Wochen gab, nachdem der Cubie doch fast jahrelang nahezu problemlos lief.
auch mit dem neuen Kernel hatte ich das hägen-bleiben Problem.
Seit dem ich die CPU Frequenz wie beschrieben begrenzt habe, rennt er seit 1. Monat durch...
Und ja, vorher lief er bei mir ohne anpassungen und Änderungen auch fast 2 Jahre durch...
Die Ausfälle auf meinem Cubie #1 traten erst vor ca 5 monaten auf...
Zuerst war der Bootloader im NVRam zuerschossen -> jetzt boot von sd-Karte
Dann waren alle Module des Kernels "weg" -> Kernelupdate incl aller Module um ein lauffähiges System wieder zu haben
Dann Instabilitäten -> CPU Begrenzung
Jetzt Stabil
Auf meinem Cubie #2 traten sie erst nach meinem Umzug vor ca 4 Monaten auf, vorher rannte er ca 6 monate sauber durch.
Auch hier half der CPU Begrenzer
Okay, dann könnte es eine Art Hardware-Verschleiß sein und ein neuer Kernel kann ich mir sparen.
Interessant - ich lasse jetzt minütlich die Heartbeatdatei antouchen und zudem den Zeitpunkt darin loggen. Dem Watchdog habe ich 20 Minuten gegeben, vor er neu starten soll. Nun startete der Cubie heute abend tatsächlich wiedermal neu - die Zeit wird aber ununterbrochen in der Datei geloggt. Also hat irgendetwas anderes den Neustart verursacht, wie mir scheint. :o
17:36:13 war der Neustart.
Auszug aus der fhem.heartbeat:
...
Wed Jul 20 17:29:59 CEST 2016
Wed Jul 20 17:30:59 CEST 2016
Wed Jul 20 17:32:00 CEST 2016
Wed Jul 20 17:32:59 CEST 2016
Wed Jul 20 17:33:59 CEST 2016
Wed Jul 20 17:35:01 CEST 2016
Wed Jul 20 17:37:47 CEST 2016
Wed Jul 20 17:38:47 CEST 2016
Wed Jul 20 17:39:47 CEST 2016
...
Zitatdie Zeit wird aber ununterbrochen in der Datei geloggt.
ich vermisse aber ca. 17:36:00
Ja, da vermute ich aber, dass die im Neustart untergegangen ist. Die von mir angegebene Zeit des Neustarts war aus der syslog. Kann es sein, dass es ca. 15 Sekunden lang dauert, bis die ersten Daten in die syslog kommen?
ich würde den reboot mal provozieren, indem ich den touch verhindern würde. dann siehst du ja, was in dem fall zb im sys.log steht und wie sich die zeiten verhalten.
keine ahnung was der watchdog genau veranlasst. vielleicht wird ja noch versucht, einigermassen "human" runterzufahren, was dann ja auch zeit kosten sollte.
Gute Idee. Morgen geht's erst mal in Urlaub, aber vielleicht habe ich von Unterwegs mal Gelegenheit für einen solchen Test.
Mit den CPU Anpassungen rennen beide cubies schon 46 Tage durch. War vorher undenkbar
Gesendet von meinem Leap mit Tapatalk
CPU angepasst und der Cubie lief 4 Monate durch, aber jetzt in den letzten 4 W zwei Total-Ausfälle (nur Reboot möglich).
Ich würde gerne dem HW Watchdog nochmals eine Chance geben, verstehe aber die Installation nicht.
Lt. Igor wird die erforderliche Funktionalität (Aktivierung des Watchdogs für ARCH_SUN7I) im nächsten Kernel-Update integriert:
http://forum.armbian.com/index.php/topic/211-kernel-update-procedure-has-been-changed/?p=10947
Aber auch eine eigene Kompillierung wäre möglich:
http://forum.armbian.com/index.php/topic/211-kernel-update-procedure-has-been-changed/?p=11132
Die Kompilierung-Option erscheint mir sehr komplex. Das Kernel-Upgrade habe ich daher durchgeführt, bin mir aber nicht sicher, ob nun die o.g. Fkt. nun tatsächlich enthalten ist, bzw. wie ich diese - falls nun vorhanden - aktiviert werden muss; d.h. welches Modul müsste ich laden. Die Konfiguration der watchdog.conf traue ich mir zu.
danke vorab.
Okay...ich hab mich durchgewühlt und inzwischen ist das fehlende HW Watchdog Modul im Kernel integriert.
Ich konnte den Watchdog entsprechend erweitern und zumindest fkt. jetzt nun der HW Watchdog, wenn ich ein Kernel panic provoziere.
Jetzt sollte ich künftig keine "Hänger" mehr haben...bzw. wird dann hoffentlich nach 20sec gebootet.
Ist wieder eine Weile her, aber diesmal ein gutes Zeichen: Mein Cubie läuft nun seit 43 Tagen durch, so lang wie lange nicht mehr. Ich hoffe, dass es so bleibt. Die letzte Maßnahme war: Den Governor rausschmeißen, der die Taktrate anpassen soll.
Fragt mich jetzt nicht, wie ich das gemacht habe - war mal eine Nacht-und-Nebel-Aktion zwischen Tür und Angel. Die Idee dazu kommt von einem Post von @Betateilchen, den ich aber jetzt auch leider nicht mehr finde.
Jetzt liegt meine Taktfrequenz praktisch immer bei konstant 720, steigt ganz selten mal peakartig auf 912. Das mach das System offensichtlich auch ohne Governor. Verdacht des Laien: Nicht nur die zu hohe Obergrenze spielt eine Rolle, es kommt auch darauf an einen nicht zu niedrigen Wert als Untergrenze zu definieren.
Hey,
Ich leide seit einem knappen halben Jahr auch unter diesem Problem. Inzwischen habe ich raus das einige u-boot-Versionen größere Probleme machen als andere. Ein Thread dazu im Armbian Forum ist z.B. https://forum.armbian.com/index.php/topic/2866-cubietruck-freeze-after-1-3-days-with-523-xenial-uboot-problem/page-2#entry23396 .
Ich habe einen Cubie mit nem Wheezy da ist das aktuelle u-boot besser aber er hält so oder so max 10 Tage durch. Cubies mit Ubuntu Xenial laufen so 30-50 Tage bevor Sie einfach hängen bleiben.
Ich hab den Thread verfolgt und ich habe rausgelesen das CPU-Limitierung eine Lösung ist ... also wie im letzten Post auf 720 fest. Was sind andere Werte die bei Euch gehen?
Gibts andere Lösungen?
Ich hatte anfangs auch immer wieder mal Stillstand des gesamten Systems, aber nach den ganzen Maßnahmen (CPU Takt, Watchdog auf HW aktiviert) lief das System stabil.
Der Watchdog hatte evtl. 1 mal im Halbjahr gebootet.
Aber seit 3-4 Wochen habe ich alle 3-4 Tage Abstürze, d.h. der Cubietruck bleibt komplett stehen und auch der Watchdog greift nicht ein.
Keinne OS-Updates, keine Änderungen weder am Cubietruck noch Netzwerk durchgeführt.
Bei einigen Stillständen konnte ich den Logs sehen, daß kurz zuvor die CPU-Temp auf 45 Grad anstieg, obwohl keine erhöhte CPU-Last da war (die meisten Ausfällen nachts).
Ich vermute daher, daß der Cubie (steht im Keller -> 16 bis 18 Grad) einen thermischen Schaden hat, obwohl die 45 Grad nicht wirklich kritisch sein könnten.
Der Temperatur-Anstieg insbd. in der Nacht ist das einzige was mich verwunderte....
Gibt es hier irgendwelche Maßnahmen / Logs um noch weiter nach der Ursache zu analysieren?
Du könntest einfach mal versuchen, den Cubi (ohne FHEM) an die Grenze fahren und gucken, ob er stabil läuft.
Gibt dazu ein nettes Linux-Programm namens "stress"
Danke Danke für den guten Hinweis. Gleich mehrfach auf der Prod und identischen UAT ausprobiert.
läuft durch: stress -c 10 -m 5 -i 5 -d 10 -t 100
Sowohl die Prod als auch UAT steigen aber bei 7 Memory Workern aus.
Teilw. greift der WatchDog ein und bootet und bei anderen Versuchen mit diesem Parameter -m 7 bringt das Stress Programm die Abbruch-Meldung.
Mmmmhhh..stress -c 10 -m 5 -i 5 -d 10 -t 100 und vor dem Hintergrund, daß beide CTs aussteigen
und bei den "Standard"-Konfiguration durchlaufen, lassen mich (als Laien) vermuten, daß die HW doch okay ist.
Die Harddisk hatte ich zuvor separat überprüft: OK
Zitat von: Wernieman am 22 Februar 2017, 08:11:28
Du könntest einfach mal versuchen, den Cubi (ohne FHEM) an die Grenze fahren und gucken, ob er stabil läuft.
Gibt dazu ein nettes Linux-Programm namens "stress"
Meinst Du nicht, das bei einem Cubi mit (4?) Kernen dieses etwas zu heftig ist?
stress -c 10 -m 5 -i 5 -d 10 -t 100
Nehme mal weniger cpu/memory/io-Worker und lasse es dafür länger laufen.
Gut ist es, parralel sich die CPU-Temperatur anzusehen!
:)
Danke für den Hinweis. Ich wußte nicht wie hoch ich die Workers setzen sollte.
Daher drastisch reduziert und auf 1 gesetzt mit 800sec.
Und hier steigen sowowhl Prod als auch UAT aus.
ABER auf der UAT greift der Watchdog und bootet die Maschine und bei der Produktion passierte nichts und hing.
Die Temperatur gingen bei beiden knapp an die 50 Grad. Im regulären Betrieb hatte ich bis dato nicht so hohe CPU und Temperatur Werte.
Ich habe nun die Prod auf meinen Desaster-Recovery CubieTruck umgezogen (= Platine getauscht).
Ich kann mir nun den defekten(?) CT mal in Ruhe ansehen.
Nochmals Danke Danke!Zitat von: Wernieman am 22 Februar 2017, 15:16:07
Meinst Du nicht, das bei einem Cubi mit (4?) Kernen dieses etwas zu heftig ist?
Du könntest auch dedizierter Testen, also jeweils CPU/IO/VM getrennt. So könntest Du mehr das Problem "lokalisieren".
z.B:
stress -c 4 -t 100
Habe es hier mal testweise laufen lassen, habe aber auch, laut lscpu, 4 CPU Kerne.
Analog das gleiche für mem, io und disk
Zitat von: Wernieman am 23 Februar 2017, 08:10:02
Du könntest auch dedizierter Testen, also jeweils CPU/IO/VM getrennt. So könntest Du mehr das Problem "lokalisieren".
Analog das gleiche für mem, io und disk
Danke für den erneuten Hinweis! Das werde ich mir morgen i.d.T. vornehmen.
Jetzt wo der ehemalige (defekte?) PROD-CT ausgetauscht wurde, kann ich in Ruhe testen und das Problem einkreisen.