Posts by ABPSoft

    Quote

    Originally posted by Bschaar
    hat er,


    heute im IRC, 3.2.x wenn ich richtig gelesen hab :winking_face:


    Allein schon wegen ext4 bigalloc wäre alles andere auch fragwürdig. Der 2.6.18 ist inzwischen so alt, dass man ihn einschulen könnte, 2.6.39 nähert sich dem ersten Geburtstag. Wenn schon ein aktueller Kernel, dann der heute aktuelle. Wird so oder so abenteuerlich, die ersten Monate werden sicher "Interessante Zeiten".

    Quote

    Originally posted by pepo83
    Joa man kann laut Manual wohl auch noch mit:
    dd if=/dev/urandom of=/dev/hda
    zusätzlich Random zeichen drüber schreiben.


    Das /dev/urandom ist nicht gerade schnell, zumal auf der DM800. Nimm /dev/zero.


    Quote

    Aber denke einmal alles mit Nullen überschreiben sollte für meine Zwecke schon reichen. So sensibel sind die Daten ja auch nicht, will eben nur nicht das man die sofort mit einem 0815 Tool gleich wiederherstellen kann.


    Bei heutigen Platten reicht ein Zero-Write völlig aus. Heise hat das mal getestet - einmal genullt und an diverse exzessiv teure Datenretter weitergegeben. Niemand konnte was retten. Die Vorsichtsmaßnahmen (mehrfach mit wechselnden Zufallsdaten überschreiben) stammen alle aus einer Zeit, als man die Bits auf den Platten noch mit einer Stecknadel treffen konnte. Die Physik ist dort heute eine ganz andere (GMR, perpendicular domains etc). Aktuelles aus den Labors der Spooks hört man natürlich nicht :winking_face:


    BTW, wenn es schnell gehen soll (was bei dem lahmen SATA der 800 eh relativ ist), nimm gleich eine vernünftige Blockgröße. Also letztlich:

    Code
    dd if=/dev/zero of=/dev/sda bs=1m


    HTH,
    Andre.

    Hi,


    meine DM800HD-C hat im letzten Jahr eine zunehmende Anzahl von Enigma2 Crashes (Greenscreens) hingelegt, die im Crashlog ungefähr so aussehen:

    Es ist vorher keinerlei Verursacher auszumachen und auch wenn es nicht klar aus dem Crashlog hervorgeht, ist das wohl ein Segfault, Bus Error oder anderweitig fatales Signal. Die Stelle im Code ist in der libpython2.6.so und ich bin so weit gegangen, das zu disassemblieren und gegenzuchecken, ja der Code der im Crashlog steht ist genau dort, aber es ist nicht offensichtlich, wieso der faulted, außer vielleicht durch einen Stack underrun. Mysteriös ist nun folgendes:

    Man beachte die relativ starke Häufung von Crashes bei Adressen, die auf 0x1484 und später 0xb484 enden. Sieht sehr nach einer Page aus, die beim Softwareupdate leicht verrutscht ist, aber vielleicht immer auf den selben Page Frame zeigt. Die Funktion in libpython, wo es jetzt kracht, ist übrigens nicht mehr die selbe, die Stelle im Code komplett anders. Nur der PC korreliert auffällig.


    Was tun?


    Der Gedanke, es könne ein RAM-Fehler sein, liegt nicht allzu fern. Und damit die Frage: Gibt es einen Memory Tester für Dreamboxen, der geeignet ist, sowas einzugrenzen? Ich denke an ein Stück Software vom Schlage von memtest86(+), also anzubooten anstelle eines Kernels, der low level den kompletten RAM so lange malträtiert, bis man was findet - oder es satt hat. Leider finde ich nichts derartiges. Das einzige, was mir unterkam, ist memtester - habe ich mir mal im OE gebacken. Der läuft im User Mode, also vorher alles gekillt, was nicht bei -15 auf den Bäumen war, damit kriege ich auf der 800er gerade so 121MiB RAM frei. Dann 24h lang memtester drüber:

    Hmm. Kann man dem Frieden trauen? Die Crashes treten meist im Abstand von Wochen auf, manchmal häufen sie sich, gefühlt besonders wenn ein HD-Sender aktiv gesehen wird (da gabs auch mal mehrere innerhalb von drei Stunden), aber dann geht's wieder wochenlang gut. Irgendwie kein klares Muster. Als es im Sommer mehr wurde, lag der Gedanke an Temperatur nahe, aber die Kiste ist eigentlich kaum handwarm...


    Also, kennt jemand einen Memory Tester, der mehr reißt als memtester? Oder andere Ansätze zur Fehlereingrenzung für solche Fälle?


    TIA,
    Andre.

    Quote

    Original von Cleaner83
    Muss doch daran liegen das der Stick zu spät gemountet wird. Wenn der Cache auf meiner Hdd liegt klappts. Allerdings hätte ich gedacht das zunächst auch der Stick gemountet wird bevor der EPG wieder eingelesen wird.


    Wer mountet den Stick? Wenn Du das von GP3 machen lässt, ist es wirklich zu spät, da E2 den unmittelbar beim Start anspricht, bevor das Plugin sich um den Mount kümmern konnte. Hatte das Problem auch anfangs und habe lange gerätselt, ich dachte das macht automount zeitig genug. Aber der automatische Mount in GP3 hat nix mit autofs zu tun - läuft also definitiv viel zu spät. Seit der Stick direkt in /etc/fstab steht, klappt das alles erwartungsgemäß.


    HTH,
    Andre.

    Quote

    Original von sat+kabel


    also willst du sagen, ard benutzt zwar die gleichen encoder intern bei allen ard-hd-sendern,


    Wieso sollte ich "das sagen wollen"? Das ist eine völlig aus der Luft gegriffene Annahme von Dir. Warst Du dort? Hast Du die Dinger gesehen? Wie viele haben die? Welche Modelle? Revisionen? Mit welchen Firmwareständen? Wer parametrisiert die? Welche Redundanzen haben die? War das Quellmaterial wirklich bitidentisches SDI? Wer stanzt das Senderlogo womit rein?


    Den Rest zu kommentieren spar ich mir, da es eh nur Trollköder ist. Wenn Du willst, kannst Du gern weiter glauben, dass ein im Video-ES gar nicht mehr enthaltenes ECC-Sideband dessen Qualität auf magische Weise verbessert. Ist ungefähr so plausibel wie Homöopathie, und das kaufen noch viel mehr Leute. Und die kommen bei der Konfrontation mit Fakten auch mit "Argumenten", sowas wie Logik wäre "skurril und hilflos".

    Quote

    Original von sat+kabel
    nach abzug dieser daten kamen am ende 3-6 megabit/s videodatenrate bei einsf. hd bei diesem "tatort" heraus.


    Wenn zwei MPEG4 AVC Elementary Streams mit vergleichbarer Datenrate deutlich unterschiedlich aussehen, dann gibt es genau einen Faktor, der dafür verantwortlich sein kann: Den Encoder. Warum einige Encoder (im selben Profil) bei einer Bitrate X nur Matsch mit Soße produzieren, wo andere noch knackscharfes Material rüberretten, kannst Du ausführlich bei Dark Shikari nachlesen. Hint: Standardisiert ist der Decoder, d.h. es ist definiert was der aus einem vorliegenden ES zu restaurieren hat (und wie ein konformer ES in einem gegebenen Profil aussehen darf). Der Encoder ist in voller Absicht nicht definiert.


    Im Übrigen ist "sah besser aus" höchst subjektiv. Audio-Esoteriker behaupten auch immer, ihre sauerstofffreien Platinkabel rauszuhören, machen aber aus irgendwelchen Gründen nie Doppelblindtests :smiling_face_with_sunglasses:


    BTW^2, wenn man die ES vergleicht, ist die FEC (oder jeder andere Parameter der Modulation und selbst des Multiplex) längst Geschichte, verrechnet bzw. weggeworfen, Verpackungsmüll. Der ES ist Netto, und das einzige was (via Decoder) am Bildschirm ankommt. Anders gesagt, das einzige was zählt.

    Quote

    Original von SuPerfrEa|<
    Und das "EPG aktualisieren" im BP ist so ziemlich das gleiche, wie das EPG-Refresh was auf dem feed als plugin zum nachinstallieren liegt.


    Würde ich jetzt nicht so sagen. GP3 EPG-Refresh macht nichts weiter, als eine handvoll Zap-Timer in die Timerliste zu setzen. Das ist wirklich alles. Das hat Vorteile und ein paar eklige Nachteile. Wenn man eine Box hat, die eh zur Zeit der Timer im Standby ist, dann stört nur, dass sie bei jedem Zap aus dem Standby geholt wird. Aber wehe, man guckt zufällig gerade live TV.


    Das extra Plugin von ritzMo zappt selbst und versucht dabei, in vielerlei Hinsicht smart vorzugehen (nur wenn im Standby und keine Aufnahme am Laufen, optimierte Kanäle bei Bouquet-Scan und Kanal-Feed aus Autotimer, konfigurierbares Zeitfenster, Scan ohne Vordergrund-Zap z.B. per Hidden PiP oder Pseudoaufnahme). Leider kollidiert es dadurch auch öfter mal mit Software-Neuerungen seitens DMM. Man sollte da checken, ob es im Zeitfenster wirklich dazu gekommen ist, mal durchzulaufen.


    Am Ende machen beide natürlich das selbe (insofern hast Du letztlich recht), und das ist kein EPG-Refresh: Sie zappen irgendwie Sender durch. Den EPG refreshed die Software so oder so von allein. Insofern können sie sich auch nur sehr bedingt gegenseitig beißen. CrossEPG andererseits lädt externe EPG-Daten hinzu und versucht, die mit denen von E2 zu mergen. Hier kann es schon viel eher krachen.


    Ansonsten: Wenn plötzlich weniger Tage im EPG sind, dann ist die Ursache - wie hier schon mehrfach gesagt - höchstwahrscheinlich der Sender. Vielleicht auch eine zu kurze Scanzeit (ein kompletter Datenzyklus ist AFAIR in 2min durch), aber dann wäre das unsystematisch mal mehr und mal weniger, nicht global weniger. Es sind Feiertage, da läuft die Technik oft auf Autopilot. Trivialitäten fixt da niemand, wenn der Zuständige erst aus dem Urlaub geholt werden müsste. Sieht man ja gerade bei RTL, die seit Tagen verstümmelte Umlaute raushauen...


    Andre.

    Hi,


    ich habe explizit noch nicht abgestimmt, da die 7020HD CC erst seit wenigen Tagen hier steht. Ich konnte im Normalbetrieb die beschriebenen Probleme bisher nicht beobachten, habe aber auch den Großteil der gemachten Aufnahmen noch nicht angesehen. Etwas ist da aber wohl schon dran, denn als ich letztens mit EPGrefresh rumgespielt hatte (extra Plugin) und mal den EPG-Scan im PiP laufen ließ, kam es bei Umschaltvorgängen im PiP gelegentlich zu Rucklern/Macroblocking im Vordergrundprogramm. Letzteres lief dabei auf Tuner B, der EPG-Scan auf Tuner A. Wirkte irgendwie so, als könne Umschalten von A den dahinter in der Kette hängenden B kurzzeitig des Signals berauben. Aber wie gesagt, bisher nur im PiP-Scan von EPGrefresh beobachtet, das könnte also auch noch andere Ursachen haben. Drauf ist momentan das neueste OoZooN 3.2.1, weil die Gelegenheit gut war, mal andere Images anzutesten.


    BTW, einen Hardwareschaden hat meine Kiste hier sehr wohl: Nach wenigen Minuten hatte das OLED einen dauerleuchtenden senkrechten Pixelstreifen. Der taucht schon beim Booten auf und geht nicht mehr weg, solange das Display Strom hat (im Deep Standby ist es endlich wieder dunkel). So'n Mist ;(. Frage mich jetzt, ob man da beim Händler auf Gewährleistung geht oder besser gleich bei DMM ein Support-Ticket aufmacht. Weiß jemand, ob das Display unproblematisch zu tauschen ist? Oder muss ich die ganze Riesenkiste quer durch die Repube schicken?


    Andre.

    Quote

    Original von AeonCor
    Noch eine Frage: Was ist der einfachste und Gemini-Kompatibelste Weg, wieder ext2 zu verwenden?


    In /etc/fstab das blödsinnige "noauto" in der ansich korrekt generierten UUID-Mount-Zeile wieder in "auto" ändern. Ich habe das als erstes probiert, als das "Einhängen" schief ging (die Zeile wird ja hinzugefügt, nur halt fehlerhaft). Danach noch ein "mount /media/hdd" und seitdem keine Probleme mehr.


    HTH,
    Andre.

    Quote

    Original von kashmir


    Wenn man den USB Stick in der fstab mountet, wird dieser direkt nach dem Start des Linux Kernels und vor dem Start von enigma gemountet und es gibt keine Probleme.


    Argh, wenn man natürlich weiß, dass es GP3 ist was den Anschein erweckt, dass ein USB-Stick automatisch gemountet wird, dann ist das zu spät oder zumindest extrem racy. Ich hatte nicht genau hingeguckt und angenommen, wenn da schon ein autofs läuft, dann wird der wohl auch verantwortlich sein, und der wird in rc3.d gestartet, bevor enigma2 in der inittab an der Reihe ist. Löst sich alles in Wunschdenken auf, wenn man mal /etc/auto.* konsultiert.


    Ok, also rein damit in die fstab und


    Test 1: Restart über Menü. EPG nachher noch da. Nur zur Sicherheit
    Test 2: Restart über BP Update. EPG immer noch da. Cool.


    Danke für die Schubse in die richtige Richtung,
    Andre.

    Hi,


    Quote

    Original von SadButTrue
    nach neustarts steht das normale epg immer zur verfügung wird für jeden neustart gesichert...


    Das wird hier zwar regelmäßig kolportiert, die Rate, mit der Leute trotzdem danach fragen, ist aber entschieden zu hoch für etwas, das "immer" funktioniert. Bei mir funktioniert es jedenfalls nicht. Es gab erst die letzten Tage wieder ein paar Updates (enigma2 und Drumrum), der dort nach der Installation ausgelöste Neustart ist ja wohl ein Korrekter und kein Crash. Trotzdem hinterher kein EPG. Vor einiger Zeit sah es mal so aus, als wäre da irgendwo ein "/" zuwenig im Code (ich finde den Thread jetzt nicht, aber es schien zu helfen, das epgCacheDir in gemini_plugin.conf mit einem "/" zu postfixen), aber das hat es auch nicht dauerhaft gebracht.


    Darf epgCacheDir überhaupt auf externen Medien liegen? Wie zeitig beim Booten wird das versucht zu laden? Nicht dass da irgendeine race condition dafür sorgt, dass das mal geht und mal nicht, je nachdem ob die Medien schon gemountet sind. Bei mir zeigte es ursprünglich auf /media/hdd und inzwischen auf /media/USB1/cache/ - vielleicht setz ich das mal 'ne Weile auf den Flash...


    Irgendwas ist da jedenfalls faul, zumindest bei der 800er.


    Andre.


    Thanks for tracking down this one! For months I wondered why some people claimed EPG data would be saved and restored over clean reboots, while others (me included) never saw that working. That trailing slash on the epgCacheDir seems in fact crucial for it to work with current code. After adding it, I've got EPG preservation over reboots all of a sudden.


    Quote

    I think this need to be reported to GP3 developers


    Second that.


    Thanks,
    Andre.

    Quote

    Original von niemand0815
    nochmal meine frage von vorher:
    hat man eigentlich irgendeinen nachteil wenn man die zeit auf ntp eingestellt lässt?


    Folgende:


    a) AFAIK holt das Plugin die Zeit einmalig beim Booten. Wenn man die Kiste also fast nie neu bootet (bei der 8000er unwahrscheinlich, bei der 800 aber an der Tagesordnung), kann die Uhr langsam wegdriften. Falls das ntpdate inzwischen in einem Cron-Job steht, leiste ich Abbitte.


    b) Wenn der NTP-Server mal beim booten nicht erreichbar ist, geht die Uhr anschließend wahrscheinlich falsch (1.1.2000).


    c) Wenn man neu flashed, Settings importiert und nicht sofort das Plugin wieder installiert (oder es mal wieder 'ne Weile vom Feed verschwindet, so dass man es nicht installieren kann), dann geht die Uhr falsch. Das Plugin setzt ja transpondertime auf false und das schleppt sich beim Settings-Import weiter.


    IMO sind das alles keine ernsten Probleme, außer vielleicht (a) bei Leuten mit einer DB, die selten rebooted wird. Ehrlich gesagt wäre mir ein korrekt eingebundener ntpd aber sehr viel lieber. Leider geht das gar nicht, weil der Kernel (zumindest auf meiner 800) ein völlig zerschrotetes NTP-Handling hat. Sobald man ntpd benutzt, um die Uhr zu disziplinieren, rennt die in irrer Geschwindigkeit davon (der Offset wächst schneller als exponentiell) - ich habe den Versuch beendet, als ich nach ein paar Minuten im Jahr 2016 war...


    HTH,
    Andre.

    Quote

    Original von gutemine
    Ihr wisst aber schon das jffs2 ein hochkomprimiertes Filesystem ist und wenn Ihr so viel auf einmal updated das nachher aussieht wie ein Schweizer Käse und auch eintsprechend performt ?


    Ich dachte mir sowas, habe das aber bisher verdrängt[1]. Bisher funktioniert das hinreichend gut und die zunehmende Fragmentierung macht sich noch nicht in exzessiven Zugriffszeiten bemerkbar[2] - die sind bei Flash wenigstens deterministisch. Auch wenn das hier oller linear flash ist und keine SSD :winking_face:


    Aber Danke für den Hinweis, das ist doch mal ein echter technischer Grund, gelegentlich neu zu flashen, und sei es nur ein Backup.


    Quote

    Macht mal eine Sicherung und restort die und schaut euch nachher und vorher den Freiplatz im Flash an. Das ist eben nicht irgend eine Linux distribition die man hochzieht auf irgend einer Harddisk die man jederzeit und leicht restoren kann.


    Sieht nur fast so aus. Der Teufel steckt im Detail.


    BTW, gibt's Tools zum Beurteilen eines JFFS2? Sowas wie dumpe2fs? Wüsste gern mal, wie zersiebt das hier schon ist. Ähm, mtd-utils hat dumpjffs2 aka jffs2dump. Mal gucken, ob das in meinem OpenEmbedded baut. Nö, natürlich ni - irgendwas mit ubifs inkonsistent. Nicht mehr heute, heute ist ja schon morgen :winking_face:


    Thanks,
    Andre.


    [1] Ich hatte erst befürchtet, dass es ein reines Zuwachs-FS wäre, das also noch nicht mal den Platz gelöschter Files freigibt. Als es dann nach dem Höchststand wieder deutlich freier wurde im /-Filesystem war die Sache für mich erledigt. IIRC war das mit JFFS (vor 2) noch hässlicher. Aber unfragmentiert neu packen ist natürlich besser.


    [2] Sofern man das bei der 800 überhaupt merkt. Die reagiert wohl immer zäh...

    Quote

    Original von knopers1
    @ ABPSoft


    Du scheinst wohl hier ein wenig mehr Ahnung haben als mancher.... BEE-Tester...


    Linux ist (zum Teil) mein Alltagsjob, daher habe ich damit keine Probleme - ich habe eine dreistellige Anzahl von Debian-Upgrades durch (seit 1995) und trau mir zu, auch arge Ruinen wieder zusammenzuflicken. Das heißt nicht, dass ich im Detail von der Dreambox Ahnung hätte. Mir ist völlig klar, dass ich das auf eigene Gefahr mache, dass ich widrigenfalls neu flashen muss - und wenn es richtig kracht, das serielle Kabel aus dem Schrank holen darf, um den 2nd neu zu flashen. Aber ich mag in-place upgrades und hasse Neuinstallationen. Daher meine bisher erfolgreichen Versuche, iCVS einfach upzugraden statt neu zu flashen. Das neue iCVS-Image (und ein FlashBackup vom alten, plus sichergestellte Dateien und ein GP3Settings-Backup) liegen natürlich extern vor, bevor ich zuschlage.

    Quote

    Kannst Du mir mal sagen wie Du dein Update ohne neuflashen gemacht hast?
    Würde es wenigsten versuchen, bevor ich mir das CVS (ohne ständiges neuflashen) draufspiele... :winking_face:


    Wie maxl auch schon mehrfach andeutete: In /etc/opkg alle Feed Configs manuell anpassen auf das neue Feed-Datum (22032011 wurde ja inzwischen "offiziell bestätigt"). Viel Platz im Flash frei haben. Dann "opkg update". Wenn das gut läuft, tief durchatmen und "opkg upgrade". Dabei darauf achten, dass alles Wichtige sauber abläuft. Hier insbesondere der 2ndstage upgrade:



    Danach ein beherztes "reboot" und Daumen drücken. Wenn *irgendwas* schiefgeht, dann musst Du das aber selber flicken können, und gerade bei diesem Upgrade könnte das eklig werden, wenn es den 2ndstage zerlegt. Also serielles Kabel, PC und Windows für DreamUp zumindest zur Hand haben.


    Die "Anleitung" ist absichtlich so knapp. Entweder man weiß was gemeint ist und kann blind mit SSH und vi(1) auf der Dream rumgurken, oder man weiß, dass man es besser lässt. Genau deswegen wird Neuflashen empfohlen - das ist ein Reset auf ein known package, keine potenzielle permutative Explosion von Dingen, die alle schiefgehen können - und Murphy sagt, das sind alle :winking_face:


    Mir ist völlig klar, dass das niemand supporten will - ich auch nicht :winking_face:


    Du musst wissen was Du tust.


    HTH,
    Andre.

    Quote

    Original von netman
    Bis jetzt haben alle Images auf dem CVS 3.0.* aufgesetzt. Seit dem letzten Update
    wurde auf CVS 3.1.* gewechselt mit einer Menge Änderungen die so gross sind, daß
    ein Update nicht funktionieren würde. Die Boxen haben schlichtweg zu wenig Flashspeicher.
    Deshalb ist ein Neuflashen unumgänglich :winking_face:


    Meine 800 hatte vorher 17.1MB freien Flash, während des "opkg upgrade" habe ich ein bissel drauf geachtet, das dabei gesehene all time low war


    Code
    Filesystem           1K-blocks      Used Available Use% Mounted on
    /dev/root                61440     46116     15324  75% /


    Das war völlig entspannt :winking_face:


    Quote

    Das ganze war ein Major Release :winking_face:


    Mag sein, aber der Upgrade auf 01022011 (von der vom 23.12.2010) hat mehr gerummst. Da war ich IIRC bis auf 11MB runter. Damals kamen jede Menge gstreamer-Updates mit, dagegen war das hier Kindergeburtstag. Eigentlich nur Kernel+Module und E2, plus etwas Drumrum (incl. Secondstage). Und E2 kracht auch nur so wegen der l10n. Wenn die mal in einzelne Pakete ausgegliedert würden (aber das müsste wohl DMM machen, ihr wollt sicher kaum die Paketstruktur inkompatibel ändern)...


    HTH,
    Andre.

    Quote

    Original von netman
    Hier ist aber aktueller Stand mit updates 26.03.2011. Fehlen wohl doch ein paar
    Updates :winking_face:


    Beziehst Du dich auf das 22032011? Das ist das Feed Tag, das ich manuell ermittelt habe. War das falsch? Ich war zu faul, das NFI auszupacken um nachzusehen, und sogar zu faul für einen wget-ad-hoc-Script (der 3. Versuch war ja schon erfolgreich)...


    Quote

    Es kommt auf dein Image an. Wenn ich deine Signatur sehe, dann sehe ich iCVS, das
    kann also nicht upgedatet worden sein (ausser du hättest irgendwelche Feeds manuell
    hinzugefügt, von denen ich dringend abrate). Also von welchem Image sprechen wir?


    Von iCVS (NFI 20101223, bereits genau so hochgezogen auf 01022011) und allen relevanten Feeds umgestellt auf 22032011. Ist ja keine Raketenwissenschaft :winking_face:


    Code
    root@dm800:~# cat /etc/version ; opkg list-installed | egrep 'seconds|kernel-im'
    201012232120
    dreambox-secondstage - 82-r0
    kernel-image - 2.6.18-r11.0


    Wieso rätst Du dringend ab? Außer, dass es nicht getestet ist. Das meinte ich: Wenn ihr böse Showstopper vorher wisst, wäre es cool die zu benennen (statt eines opaquen "geht nicht").


    Thanks,
    Andre.

    Quote

    Original von netman
    Psst: Ich verrate dir was, alle müssen neu flashen :winking_face:


    Welchen exakten technischen Grund hat das?


    Ich frage nur, weil hier gerade ein manueller Upgrade auf 22032011 anstandslos durchgelaufen ist. :hurra:


    Secondstage wurde hochgezogen (da ist es wohl besser, genau auf die Ausgaben zu achten), Kernel und Driver sind neu, Aufnehmen & Wiedergeben geht (letzteres war wohl die Crux bei Secondstage/Driver/E2-Mischmasch).


    Mir ist klar, dass ihr das nicht supporten wollt - ich sehe aber schon noch einen Unterschied zwischen "das geht zwar, aber wenn Du nicht selber weißt, wie, dann flashst Du besser neu" und "das geht nicht, weil dann XYZ passiert/nicht passiert". Insofern wäre ein klarer Warnhinweis angebracht, wenn es mal keinesfalls upzugraden geht - mit 'ner nachvollziehbaren Begründung. Man will die Kiste ja nicht bricken :winking_face:


    Thanks,
    Andre.

    Hi,


    ich bemerke gerade eine zunehmende Zombie-Horde:


    Code
    root@dm800:~# ps | grep Z | grep -v grep | wc -l
    134


    Nach etwas Rumgesuche wird klar:


    Die Zombies werden mehr, sobald die Infobar aktiv ist. Sekündlich. Mit ein paar flott nacheinander abgesetzten ps und etwas gegurke in /proc lässt sich zeigen, dass es Child Processes von /usr/bin/gdaemon sind, die von der HDD Temp Anzeige getriggert werden:


    Code
    3552 root      2532 S    sh -c smartctl -d ata -A /dev/sda 
     3553 root      3920 R    smartctl -d ata -A /dev/sda


    sieht anschließend so aus


    Code
    3552 root         0 Z    [sh]


    und bald sind es wieder ein paar mehr.


    Sieht also aus, als würde gdaemon seine Children nicht ordentlich reapen.


    Code
    root@dm800:~# opkg search /usr/bin/gdaemon 
    geminitools - 0.23-r0


    Mir scheint, dass das neu ist, gestern habe ich das Upgrade auf 0.24-r10 eingespielt. Ich bin aber auch vorhin mal der Empfehlung gefolgt, diverse Caches und Picons auf einen USB-Stick auszulagern, damit ist also noch was anderes geändert worden. Und wenn es um HDD Temp geht, mag die Anwesenheit eines /dev/sdb schon irgendwas beeinflussen können - wenn auch eigentlich nicht das child reaping in gdaemon.


    Sieht das noch jemand?


    Image ist das iCVS vom Februar.


    BTW, hatte nach dem Upgrade gestern beim Reboot nach dem allerersten Bootlogo kein Bild mehr, die Kiste war fast tot aber nicht ganz (Spinner kam noch, Menü ging noch). Nach einem Power Off und 5min Kurzurlaub ging dann aber erstmal wieder alles.


    TIA,
    Andre.