Dreamboard

Ghost · 26. Januar 2011

Hi,

das fixt aber nichts, außer dem reinen Text.

Wir sind an dem Problem drann... und nein.. es hat nichts mit irgendwelchen billigen NAND Chips zu tun... zumal die Micron Chips keine Billig Chips sind.. und die 8000 auch gar nicht in China produziert wird.

Warum es mit dem alten kernel nicht auftrat wissen wir noch nicht. Wir vermuten da ein Timing Problem im Nand Treiber.... der alte kernel 2.6.12 war da einfach um etliches langsamer.... aber wir gesagt.. wir sind da drann.

Sobald es was neues gibt melden wir uns da.

cya

prtigger · 26. Januar 2011

Hallo Ghost,

vielen Dank für Deine Information an dieser Stelle. Da fühlen wir uns hier gleich nicht mehr so allein !

Klar fixt das nicht mehr in "nand.h". Sieht halt nur besser aus.
Ein Timing-Problem habe ich auch schon früher hier vermutet... warten wir ab, was Ihr rausfindet.

Danke und viele Grüße,
prtigger

freeman · 26. Januar 2011

Ghost,

kannst du dir bitte mal diesen Link anschauen.

http://www.kernel.org/pub/linu…/broken-out/git-mtd.patch

Über die Recherche von David Woodhouse ein Entwickler von JFFS2 bin ich darauf aufmerksam gemacht worden.

Ich möchte ja nur helfen.

Ich spreche auch über mögliche Ursachen.

Momentan stochern wir alle mehr oder weniger im Nebel.

Und man greift nach jedem Strohhalm.

Ich habe nur gesehen das OOZOON schon den kernel-2.6.18-r8.0 verwendet.

Kannst du etwas zu diesem Kernel und den Treibern was sagen.

Vielen dank im Voraus.

mfg.

freeman

Ghost · 26. Januar 2011

Hi,

keine Ahnung was oozoon da hat.. aber es wird nichts mit dem Problem zu tun haben... er hat halt irgendwas am kernel angeschaltet in der config und dazu nur die kernel revision hochgesetzt.

Der von dir angegeben patch wird auch nichts bringen. Das ist kein Bug im mtd layer oder im jffs2. Das scheint einfach ein bug in unserem nand treiber zu sein. Und den müssen wir halt erstmal analysieren.

cya

prtigger · 26. Januar 2011

Vielleicht ist es auch sinnvoll die Kernel Changelogs im Bezug auf das JFFS2 durchzuschauen. Im Kernel 2.6.24 ist z.Bsp. Einiges gefixt worden.
Aber ich muß Freeman recht geben: Wir stochern im Nebel...

(Upps Ghost Du warst schneller, warum schließt Ihr das JFFS2 oder mtd layer aus?)

Viele Grüße,
prtigger

OoZooN · 27. Januar 2011

ich hab gar nix hoch gesetzt. obi war's, damit das tun modul gebaut wird. das wurde bei mir aber schon ewig gebaut ...

freeman · 27. Januar 2011

Ghost und Oozoon,

erstmal danke für die Infos.

Ich hatte schon gesehen das es im Oktober 2010 schon mal anpassung bezüglich Summaries gegeben hat.

Siehe auch hier: http://git.opendreambox.org/?p…e3850aca3abbff76443f65d6f

mfg.

freeman

prtigger · 27. Januar 2011

Hallo Freeman,

ich habe mir zum Spass gestern mal die ganzen Changelogs bis 2.6.24 angeschaut....
Die meisten Änderungen bezüglich JFFS2 sind im Kernel 2.6.24 aufgegangen. Das sind schon einige Stufen von unserem 1.6er Stage
entfernt. Aber Ghost ist ja der Meinung der Fehler ist dort nicht zu suchen... Zu den NAND Treibern kann ich nichts sagen. War bisher
der Meinung, dass die zum Kernelpaket gehören... aber ich bin da wohl nicht mehr auf der Höhe der Zeit. Ich kann Dir nur empfehlen
den 24er Kernel Changelog mal zu sichten...

Trotzdem können wir nun nur abwarten und hoffen,
dass die Entwicklung irgendwas findet.

Viele Grüße,
prtigger

tomde · 2. Februar 2011

Ich warte seit Anfang 2010 darauf und die aktuellen Antworten und Aktivitäten stimmen mich optimistisch - dank an alle die etwas beitragen.

Wir haben gestern mal ein OE1.6 experimental vom 1.2.11 geflasht und alle Vorgänge geloggt (incl. Timestamps): Hoffe es hilft ein wenig. Es zeigt wie oft die dm8000 hier: Production Date: 2010/04/27, mID 10 damit abstürzt.
Interessant ist, wenn man ein "okay-log" und ein "Fehler-Log" mal nebeneinander vergleicht - da fallen Fehler auf, die im okay-log beim nächsten Booten nicht auftreten, so z.B. beim fehlenden DVI-Ton - es bleibt aber beim erwähnten stochern im Nebel...

Code

Hier die Beschreibung zu den einzelnen bootlogs


1.Start mit dem bootlog des stabilen 2.8.4: (ZOC_110201-1456_TAB01_2.8.4.LOG)
2.Dann das experimental-dm8000_20110201.nfi geflasht: (ZOC_110201-1623_TAB01_flashing.LOG)
3.Nach dem Grundkonfiguration mit Installationsassistenten hatten wir erstmal keinen DVI-Ton: (ZOC_110201-1639_TAB01_3.0.x_konfiguration_kein_DVI-ton!.LOG)
4.Nach dem Reboot immer noch keinen DVI-Ton: (ZOC_110201-1649_TAB01_3.0.x_reboot_kein_DVI-ton!.log)
-Deshalb die Box eine Stunde ausgeschaltet.
5.Wie erhofft startet das 3.0.x nun erstmalig sauber mit Bild und Ton (ZOC_110201-1802_TAB01_3.0.x_ok.LOG)
6.Reboot: das 3.0.x restartet wieder sauber (ZOC_110201-1812_TAB01_3.0.x_ok.LOG)
7.Reboot: der restart dauert viel länger, da ECC error, kernel panic und ein auto reboot stattfand, danach kommt aber Bild+Ton (ZOC_110201-1815_TAB01_3.0.x_laengerer_boot.LOG)
8.Reboot: Absturz nach ECC error, JFFS2 notice (1): (ZOC_110201-1821_TAB01_JFFS2 notice_ausgeschaltet.LOG)
9.Aus/Eingeschaltet: Absturz nach ECC error, JFFS2 notice (1): (ZOC_110201-1825_TAB01_JFFS2 notice_ausgeschaltet.LOG)
10.Aus/Eingeschaltet: das 3.0.x restartet wieder sauber (ZOC_110201-1828_TAB01_3.0.x_ok.LOG)
11.Reboot: Absturz diesmal nach ECC error, JFFS2 notice: (389): (ZOC_110201-1830_TAB01_JFFS2 notice (389)_Fronttaster reagierte erst nach 10-20 maligem Drücken.LOG)
12.Ausschalten gelang erst nach vielen Fronttasterbetätigungen: das 3.0.x startet wieder sauber: (ZOC_110201-1833_TAB01_3.0.x_ok.LOG)
13.Reboot: Absturz nach Bus errors, INIT: Id "e2" respawning too fast (ZOC_110201-1837_TAB01_e2 respawning too fast.LOG)
14.nochmal die Bus Errors: (ZOC_110201-1839_TAB01_Fronttaster reagierte erst nach 10-20 maligem Drücken.LOG)
15.Aus-/einschalten gelang erst nach vielen Fronttasterbetätigungen: Absturz nach JFFS2 notice: (1) (ZOC_110201-1854_TAB01_JFFS2_reboot_nach einmaligem drücken.LOG)
16.Einschalten: das 3.0.x startet ein letztes Mal sauber (ZOC_110201-1904_TAB01_okay.LOG)
17.Und dann zum Fernsehen lieber wieder das 2.8.4: (ZOC_110201-1909_TAB01_2.8.4....LOG)

Alles anzeigen

prtigger · 2. Februar 2011

Hallo Tom,
danke für Deine Logs. Habe mir die mal ganz in Ruhe angesehen. Das Problem stellt sich bei Dir doch etwas anders da, als bei mir. Bei Dir stürzt scheinbar
nach einem CRC bzw. ECC Fehler gleich die ganze Box weg. Das tut meine (zumindest mit 3.0.3) nicht. Ich habe auch teilweise mehrere CRC bzw. ECC Fehler im
Bootlog. Bei mir läuft das Betriebssystem immer noch und ich komme mit Telnet auf die Box und fahre sie dann sauber runter. Die Box bleibt in einer Schleife ab
"Executing Main" mit ["e2" respawning too fast] hängen. Wie schon am Anfang des Threads beschrieben. Optisch bootet die Box bis zur Hälfte und dann
schaltet sich das Anzeigedisplay ab und die Poweron-Taste leuchtet. Der Enigmastart schlägt also fehl. Ich habe die neueren Images bisher nicht getestet.
Die Box hat momentan "Urlaub", bis ich hier ein neues Feedback von der Entwicklung habe, dass die was geändert haben --> neuer Test.
Die Frage ist: Kommst Du nicht mehr mit Telnet auf die Box und kannst sie dann runterfahren? Ich gehe davon aus, dass das bei Dir nicht geht.

Viele Grüße,
prtigger

tomde · 3. Februar 2011

Hallo prtrigger, danke fürs ansehen der Logs, hatte schon befürchtet die Mühe sei umsonst, aber vielleicht hilfts ja auch dem Support ein wenig.
Ja, die Absturzzeitpunkte sind bei mir unterschiedlich (ohne bootlog am oled statusbalken zu erahnen, gab aber auch Abstürze, wo noch kein Balken erschien)
Telnetzugriff habe ich leider nicht probiert, wenn das bootlog stehenblieb, danke für den Tipp - werde es das nächste Mal testen.
In dem Dutzend reboots mit dem experimental-dm8000_20110201.nfi hatte ich auch einen ["e2" respawning too fast].

Wichtig finde ich, dass die Auswirkungen / Fehlerbilder bei jedem bootvorgang etwas anders sein können. Und das ist mir mit allen der 4 reklamierten dm8000 Boards/Boxen und mit allen OE1.6 Images im letzten Jahr aufgefallen. Deshalb schicke ich die aktuelle Box erstmal nicht zurück, sondern warte auf den Support und nutze weiter das 2.8.4.release
Viele Grüße, Tom

prtigger · 3. Februar 2011

Hallo Tom,
zu meinen Abstürzen (das sind die häufigstens beim 3.0.3) kann ich nur sagen:
Finde ich folgende Zeilen ab "Executing Main" im Bootlog:

executing main
setIoPrio best-effort level 3 ok
Traceback (most recent call last):
File "/usr/lib/enigma2/python/mytest.py", line 3, in <module>
import enigma
File "/usr/lib/enigma2/python/enigma.py", line 376, in <module>
class iPauseableServicePtr(object):
File "/usr/lib/enigma2/python/enigma.py", line 381, in iPauseableServicePtr
__swig_destroy__ = _enigma.delete_iPauseableServicePtr
AttributeError: 'module' object has no attribute 'delete_iPauseableServicePtr'
---- saving lame channel db
main thread is non-idle! display spinner!
saved 84 channels and 1524 services!
release cached channel (timer timeout)

dann bleibt die Box nach halbem Boot mit dunklem Display und leuchtender PowerOn-Taste hängen. Ähnliches habe ich in Deinen Logs nicht gefunden.
Aber auch Freeman hat unterschiedliche Formen der Abstürze, wie er mir heute bestätigt hat. Ist schon alles sehr komisch.

Viele Grüße,
prtigger

tomde · 4. Februar 2011

Hallo prtrigger, bis "executing main" (runlevel: 3) kommt die Box bei mir nicht, wenn sie JFFS2 notice, ECC error, Bus error, "Id "e2" respawning too fast", kernel panic oder ähnliche Sorgen meldet.

Einen "AttributeError" o.ä. finde ich bei mir nirgends. Könnte bei Dir ein Problem sein, vielleicht mit der Senderlistendatenbank? Hast Du nach dem flashen des 3.0.3 mit dem Startassistent alte Einstellungen übernommen? Ich hatte für den Test alles neu konfiguriert und ohne zusätzliche Plugins zu installieren. Auch die default Senderlisten für ASTRA+Hotbird hatte ich geladen.

Gruß Tom

prtigger · 4. Februar 2011

Hallo Tom,
ich habe die Einstellungen der Box grundsätzlich neu durchgeführt. Dann meistens meine Senderliste über das DCCE2 zurückgespielt.
Ich habe aber auch Tests gemacht bei denen ich nur die Standardkanalisten bei der Konfiguration lade. In einem früheren Test habe
ich auch einmal den Sendersuchlauf bei der Grundinstallation verwendet. Hat keinen Einfluss.... kein Unterschied.
Ich sehe das Problem definitiv beim Kernel. Ob nun Flash Treiber oder JFFS2 Probleme.

Ghost: Könnt Ihr den Fehler bei euch mittlerweile reproduzieren?

Viele Grüße,
prtigger

Ghost · 10. Februar 2011

Hi,

soo .. also nach mehreren Tagen Fehlersuche hab ich nun einen Fix eingecheckt.. im aktuellen Experimental ist er seit eben enthalten. (Aktueller kernel 2.6.18 )

Wäre Nett wenn das mal nen paar ausprobieren könnten und dann hier Feedback geben. Ich selber kann das Problem damit nun nicht mehr nachvollziehen. Also es tauchen bei mir keine mtd->read errors mehr im kernel log auf.

cya

prtigger · 10. Februar 2011

Hallo Ghost,

danke für die Info. Ich werde das erst in gut einer Woche nach meinem Urlaub testen können --> dann gibt es Feedback.
Mich würde noch interessieren was ihr geändert habt, falls sich das kurz kommentieren läßt.

Viele Grüße,
prtigger

freeman · 11. Februar 2011

Hallo Ghost,

ich werde es heute abend checken.

Ich habe gesehen das auch ein neuer Kernel Release veröffentlicht wurde kernel_2.6.18-r9.1_dm8000.ipk.

Ich hatte das experimental vom 5.2.2011 geflash gehabt und dann ein update auf den Stand 8.2.2011 durchgeführt.

Da waren die Probleme noch nicht beseitigt gewesen.

Ich werde heute abend den Release Stand experimental-dm8000_20110210.nfi flashen und mit protokollieren.

mfg.

freeman

tomde · 11. Februar 2011

Danke sehr, Ghost,

hab das experimental-dm8000_20110210.nfi geflasht und dann 9 x rebootet, jedesmal ein Log erstellt und bis zum erscheinen von Bild+Ton gewartet.

Zwei Sachen sind mir in den Logs aufgefallen:

Das 4. Reboot-Log (ZOC_110211-0945_TAB01_4..LOG) zeigt kurz vor Entering runlevel 3:
JFFS2 warning: (668 ) jffs2_sum_write_data: Not enough space for summary, padsize = -388
Das 8. Reboot-Log (ZOC_110211-1013_TAB01_8.LOG) zeigt 30 Sekunden nach init 3:
JFFS2 warning: (903) jffs2_sum_write_data: Not enough space for summary, padsize = -369

Einen Absturz hatte ich bei den 9 reboots keinen, auch oben genannte: "JFFS2 notice, ECC error, Bus error, respawning too fast, kernel panic" konnte ich nicht mehr entdecken.

Anbei alle Logs, freut mich wenns hilft, Grüße Tom.

Ghost · 11. Februar 2011

Hi,

das mit dem Summary ist kein wirkliches Problem. Also das macht nichts. Und ist laut code einfach so.. und auch nicht zu ändern.

Das Summary wird auch nur zum schnelleren mounten des fs benutzt. Diese Warnung heisst aber nicht, dass das komplette Summary nicht benutzt wird.. sondern nur ein Teil.

Wie gesagt.. laut code ist das okay.

cya

tomde · 11. Februar 2011

Gut, ist dann für mich auch okay - zumal ich beim Auftreten des Not enough space for summary keine Auswirkungen auf die Funktionsweise sehe und die Box ja beim Starten nicht daran hängen bleibt.

Würde aber trotzdem gerne verstehen, wieso die JFFS2 warnings in 2 von 8 Reboot-Fällen auftreten (und in diesen Fällen ein Teil nicht genutzt werden kann) und in den anderen Fällen (ohne eine Veränderung) nicht auftreten?