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

Der Header Patch für die Micron Bausteine:

commit 972edcb79ec8c8512ed5b29ca6718065328d6992
Author: Vitaly Wool <vitalywool@gmail.com>
Date: Sun May 6 18:46:57 2007 +0400

[MTD] [NAND] platform NAND driver: update header

This patch extends nand.h in order to enable platform NAND driver.

Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>

ist im Kernel 2.6.22 enthalten
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.22

Viele Grüße,
prtigger

Hallo Tom,

davon bin ich ausgegangen (Unknown). Warum sollte das auch in einer älteren Kernel-Version anders sein. Im Kernel 2.6.21.7 ist das jedenfalls
in nand.h noch nicht gefixt (wie Freeman geschrieben hat). Und von dem Kernel sind wir auch noch sehr weit weg.

Viele Grüße,
prtigger

Hallo Tom,
die Frage die sich nun aber trotzdem stellt ist:
Was meldet das Release 2.8.4 für einen NAND Typ. Schätze, das wird auch 'Unknown' sein. Von Dir wissen wir ja, dass der 1.5er Release läuft. Wie
schon mehrfach geschrieben, habe ich den nie auf der Box gehabt. Ob also die korrekte Typdefinition in der .h-Datei etwas bringt ist sehr fraglich.
Leider konnte ich den beschriebenen Patch von Freeman nicht nachvollziehen. Quellenangabe wäre nett gewesen. Es muß schon mehr gepatcht werden
als nur eine Speicherherstellerdeklaration. Aber da gehe ich mal von aus...

An die Entwicklung: Gibt es von Euch irgendwas Neues zu dem Thema... Bitte ein kurzes Feedback hier... Danke!

Viele Grüße,
prtigger

Hallo Freeman,

wie schon besprochen, hoffe ich, dass Du diese Informationen auch an den Support gemailt hast. Denn die Entwicklung hält sich in diesem Thread
bisher leider sehr bedeckt. Ich frage mich nur was Dream geändert hat, denn der 1.6er Exp. Stage lief ja auch mal stabil. Oder es war Zufall und ich
habe es nur nicht bemerkt, da ich die Box nur unregelmäßig in Verwendung habe. Vom Gefühl her sehe ich das Problem auch beim Kernel und den Flash
Treibern. Ich habe nur keine Erklärung dafür, dass die Box nach einem Boothänger (50% Boot) manchmal absolut fehlerfrei hochfährt.... und warum
melden sich hier nicht reihenweise Leute mit diesem Problem???? Hardwareprobleme schließe ich jedenfalls momentan aus.

(PS: Vielleicht wäre noch ein Link auf den mtd-patch hier nicht schlecht. Ich habe ihn nämlich nicht gefunden. Vielleicht bin ich aber auch zu blind)

Viele Grüße,
prtigger

Hallo freeman,

bitte auch den Support informieren, denn ob die Entwicklung diesen Thread mitliest und Deine Informationen weitergibt, ist momentan fraglich !

Viele Grüße,
prtigger

Hallo Ararat,

grundsätzlich gebe ich Dir recht. Warum warten....?
Weil ich erwarte, dass wenn man seid langer Zeit ein Ticket bei Dream offen hat und im Telefonkontakt steht, dass man auch mal ein Feedback
bekommt, wenn ein Experimental Stage eine mögliche Lösung des Problems bietet.... Leider warte ich darauf noch. Ist es also Zufall wenn es
bei euch nun scheinbar funktioniert oder wurde etwas am Image geändert.... und wenn ja, dann würde mich sehr interessieren was!!

Danke für Dein Feedback,
viele Grüße,
prtigger

Hallo freeman,

ich habe den Dreamsupport (Hrn. Teuser) darum gebeten mir eine Information zukommen zu lassen, wenn ein Experimental Image existiert,
das möglicherweise eine Problemlösung bietet. Bisher habe ich noch nichts Positives dazu gehört. Nur soviel, dass die Entwicklung sich damit
beschäftigt.

Viele Grüße,
prtigger

Hi crashman,

in your first post here, you talk about CRC, ECC errors during boot. My question is:
Do you recognize boot hangs (half boot, display off) during startup, too... because this is the problem, we have the focus on.
This may be relating on a jffs2 filesystem timing or driver problem... but i´m not sure, because CRC errors may be normal
(see early post from freeman:
According to Dave Woodhouse, who wrote JFFS2, these notices typically
mean that at some point you've hard powered off, and as a result JFFS
has some uncommitted data lying around on flash. It's almost always
harmless, a part of the journal which was never committed: "either it
was a new write which hadn't yet been synced, or it was a GC write
which just doesn't achieve anything now." However, these messages
*could* indicate an actual problem -- "we never came up with a good
heuristic for when _not_ to complain". Woodhouse suggests that in the
future "perhaps we should write a 'yes, I know there's a CRC failure'
node _after_ the offending node, when we reboot and find it" since
directly rewriting the node is not an option due to the mechanics of
NAND flash; that would help confine these messages to immediately
after a hard reboot. At present, you'll keep seeing a "bad CRC"
message every time that particular JFFS node is accessed until it is
eventually GC'ed.)

Using USB stick may be a workaround, too .... but i want to use the box how it is designed from Dream, with original firmware on it,
because i´m not a real good Linux specialist (to long ago i played around with it).

Best regards,
prtigger

Hi crashman,

i think it´s not a flash memory problem. Changing flash memory (due first repair) and changing the whole box (second repair) didn´t solve the problem.
I think it´s more a driver-, kernel-problem. A workaround is not a solution for the problem with the 1.6 stage (3.0.x). Dream needs to investigate
the boot hang problem. In addition, keep in mind, that the 2.8.4 release (stage 1.5) is working for Tom. I never used this stage on my box.

Best regards,
prtigger

Hallo Tom,
hallo el_tonno,

el_tonno:
Danke für Deine Info.... Jetzt bin ich wieder etwas schlauer.

tomde:
Das sieht alles nach dem aus, was ich kenne. Vielleicht solltest Du Dich auch zusätzlich mit Herrn Teuser in Verbindung setzen,
dass der sich auch mal mit Deinem Ansprechpartner zusammensetzt. Bei meiner Box haben die keinen Langzeittest gemacht.
Meine aktuelle Box ist Herstellungsdatum xx.10.2010 also topaktuell.

Ich hoffe es melden sich noch mehr Leute bei Dream mit dem gleichen Problem. Nur dann werden die auch eine Lösung finden.

Viele Grüße,
nochmal einen guten Rutsch,
ich freu mich auf Urlaub... Keine Bootlogs erstellen für eine Woche !

prtigger

Hallo el_tonno,

Frage: Wie flasht Du nur den Secondstage-Loader (Welches Paket, welcher Befehl)?
Ich beschäftige mich noch nicht so lange mit der Dreambox und bin für Tipps und Tricks immer dankbar.

Ich gehe nicht von einem Flash Problem aus. Dann müßte es schon einen Serienfehler bei den Flashbausteinen
geben. Meine erste Box, die getauschen Flashbausteine und die neue Box zeigen das gleiche Verhalten.
Um zu testen ob die Box stabil läuft braucht man ca. 5-15 Bootvorgänge aus dem Deep-Standby.
Komisch ist, dass die Hänger meist schon beim dritten Boot auftreten, wenn die Box längere Zeit (1-3 Tage)
völlig stromlos war. Eine Erklärung habe ich dafür nicht, es ist mir aber aufgefallen. Das das JFFS2 dabei
irgendwie zerschrieben wird schließe ich aus, denn wie erklären sich die absolut CRC- und ECC-fehlerfreien
Bootvorgänge zwischendurch.

Die Gretchen-Frage ist: Warum haben nicht mehr Leute das gleiche Problem mit dem aktuellen 1.6er Stage.
Ich kann mir nicht vorstellen, dass die alle noch den 1.5er verwenden (habe ich nie auf meiner Box gehabt).
Der Experimental-Zweig lief bei mir Anfangs sehr stabil. Oder haben die die Box alle im Standby und fahren
das System nicht vollständig runter, wenn Sie nicht TV schaun. Mir braucht die Box im Standby zuviel Strom,
daher fahre ich immer schön runter.

Sieht für mich weiterhin nach einem Software/Timing Problem aus. Nur sowas produziert solch komisches
Verhalten (wenn man die Hardware ausschließen kann).

Viele Grüße,
prtigger

Hallo Tom,
ich kenne Deine anderen Posts hier im Forum. Ich verfolge die schon seit dem ich auf meine Probleme gestoßen bin.

Wichtig ist, dass was ich in meinem ersten Post hier geschrieben habe. "Executing Main" Dauerschleife bis
"INIT: Id "e2" respawning too fast: disabled for 5 minutes". Dann hängt die Box. Findest Du Identisches im
Bootlog, dann haben wir exakt das gleiche Problem. Ich bin dazu mit Herrn Teuser vom Dream Support
seid länger Zeit im Kontakt. Leider konnte der das bisher nich reproduzieren. Ich sehe momentan
auch keinen Anlass die Box zum dritten Mal einzusenden, da Dream nicht, wie im RMA beschrieben, nur das
Mainboard gewechselt haben, sondern gleich die ganze Box getauscht haben. Es sieht momentan nach
einem Kernel/Treiber-Problem aus. Vielleicht auch ein Timingproblem. Alles wage!! Ich habe jedenfalls
nie ein Image aus der 1.5er Schiene auf meiner Box gehabt. Ich habe die nun 4 Monate und sie lief
lange Zeit mit dem Experimental-Zweig stabil. Leider hatte ich die Box über längere Zeit nicht in
Betrieb und die Probleme tauchten erst mit Rel 3.0.0 auf. Dann plötzlich habe ich aber auch ältere
Images nicht mehr stabil zum Laufen bekommen und bin daher von einem thermischen Hardwaredefekt
ausgegangen, da sich die Fehler auf der Box von "Freeman" nicht reproduzieren ließen. Erst Flashspeicher
tausch und nun Boxtausch--> Fehler identisch. Von einem Serienfehler in der Produktion gehe ich nicht
aus, da Du eine ältere Revision hast. Irgendwie müssen wir aber herausbekommen wie sich der Fehler
reproduzieren läßt, damit Dream den Fehler nachstellen kann. Erst dann gibt es eine Chance, dass die
das abstellen. Komisch nur, dass sich hier nicht reihenweise Leute mit dem gleichen Problem melden.
Den Fehler müßten einfach mehr Leute haben. Ich bin ab dem 2.1.2011 für eine Woche im Urlaub
und werde mich danach wieder telefonisch mit Herrn Teuser in Verbindung setzen. Meine Testergebnisse
liegen ihm schon per Mail vor.

Irgendwer hat mir mal schlau gesagt:
Computer sind doch nur Nullen und Einsen... Alles ganz einfach!
Ich habe allerdings das Gefühl, dass es da noch viel dazwischen gibt !

Viele Grüße,
prtigger

Hallo el_tonno,
Hallo Tom,

el_tonno:
Das Problem tritt bei mir nicht nach irgendeinem Absturz von einem Plugin oder der Box auf.
Die Box ist frisch geflasht und es wurde nur eine minimale Grundkonfiguration durchgeführt.
Keine weiteren Plugins installiert! Also nur der Inhalt des reinen Images (3.0.3 beim letzten Test).
Die Box hängt bei 50% Boot... dann geht meist das Display aus und die PowerOn Taste leuchtet.
Endlosschleifen mit Greenscreen hatte ich auch schon... das produziert aber einen anderen Bootlog.
Oder der Log enthält Segmentation Faults die auch schon zum Kernel Panic geführt haben.
Momentan ist aber eher das 50% Boot ein Problem.

Frage: Was bewirkt den "opkg update" und "opkg upgrade" ???
"opkg --force-reinstall install enigma2" Sollte wohl das Enigma neu installieren.

Da ich neu flashe schließe ich diesen Fix aus..... oder durch mehrere PowerOFF und Restart Zyklen wird das JFFS2 File System
irgendwie zerschossen. Komisch ist trotzdem, das ich auch zwischendurch immer mal wieder absolut fehlerlose Bootlogs beim
Start bekomme. Sehr sonderbar -> Ich bin da ratlos aber mit dem Support im Kontakt.

tomde
Leider kann ich mit den Crashlogs nicht viel anfangen. Ich hätte lieber einen seriellen Bootlog, wenn die Box hängenbleibt.
Wende Dich jedenfalls nochmal an den Support, falls das Problem genau so aussieht wie bei mir. Die gleiche Ansprechperson
bei Dream wäre dann meiner Meinung nach sehr sinnvoll.

Viele Grüße,
prtigger

Zitat von sparksofinsanity

Ich reihe mich mal schweigend ein

Hallo,
hast Du noch ein par Informationen zu Deiner Box. Revision, Ausstattung etc.. Exakt das gleiche Problem ???

Viele Grüße,
prtigger

Hallo Tom,

Du solltest einmal genauer Deinen Bootlog durchsehen. Das System läuft bei mir noch (Komme mit Telnet drauf und kann das System sauber runterfahren).
Nur Enigma startet nicht. Der Bootvorgang läuft bei "Executing Main" in eine Endloschleife:

Bootlog Auszug bei Hänger:
....
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)
.......

Normalerweise sieht dieser Absatz so aus:

.......
executing main
setIoPrio best-effort level 3 ok
main thread is non-idle! display spinner!
[4294731.492000] bcm4506 channel 0 is sleeping now
[4294731.510000] bcm4506 channel 1 is sleeping now
[4294731.535000] 11923 ms: =s
[4294731.548000] 10 ms: 53
main thread is non-idle! display spinner!
[4294731.939000] 389 ms: 53
[4294732.076000] 134 ms: 53
[4294732.132000] 53 ms: 54
[4294732.890000] 755 ms: 54
/proc/stb/frontend/0/lnb_sense is 0

enumerating block devices...
found block device 'sr0': no medium
found block device 'mtdblock6': blacklisted
found block device 'mtdblock5': blacklisted
found block device 'mtdblock4': blacklisted
found block device 'mtdblock3': blacklisted
found block device 'mtdblock2': blacklisted
found block device 'mtdblock1': blacklisted
found block device 'mtdblock0': blacklisted
found block device 'sda': ok, removable=False, cdrom=False, partitions=['sda1']
new Harddisk sda -> /dev/sda -> /dev/sda
[ePopen] command: ('hdparm', 'hdparm', '-S0', '/dev/sda')
found block device 'sda1': error querying properties
[4294735.804000] 2911 ms: 55
not loading user skin: [Errno 2] No such file or directory: '/etc/enigma2/skin_user.xml'
.......

Das fehlerhafte Ausführen von Teil "Executing Main" wiederholt sich, bis die Box stehenbleibt bei:
......
INIT: Id "e2" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel
[4294748.134000] bcm4506 channel 0 is sleeping now
[4294748.151000] bcm4506 channel 1 is sleeping now
INIT: Switching to runlevel: 0
......

Ich habe so ziemlich alles getestet. Andere Festplatte (Seagate 7200.12 1TB), Kein DVD Brenner, gar keine Geräte angeschlossen. Die Boothänger
treten bei mir auch immer wieder auf. Heute habe ich die Box ohne Geräte geflasht (3.0.3 über WIF). CRC-, ECC-Fehler und JFFS2-Warnings traten
gleich beim ersten Boot auf. Box konfiguriert, Bouquet per DCCE2 rückgesichert und 2 mal boot aus Deep Standby -> Box hängt.
Früher lief die Box mit 1.6er Exp. problemlos. Ich kann den Zeitpunkt, wann es nicht mehr lief leider nicht greifen. Jedenfalls läuft bei mir
kein 3.x.x Rel. stabil. Wie "freeman" bereits geschrieben hat, habe ich die aktuelle Version der Box. Ob Version 6 oder 7 habe ich gerade
nicht im Kopf (Produktion 10.2010). Ist schon ein Komplettaustausch (offiziell wurde zwar nur das Mainboard getauscht). Beim ersten
Rep.-Versuch wurde der Flash-Speicher gewechselt. Hat alles nichts gebracht. Festplatte ist eine WD10EADS (1TB C.Green) und zusätzlich
ein LG GT20N DVD-Brenner und SuperRed Lüfter. Für mich sieht das nach einem dicken Softwareproblem aus. Leider gibt es aber laut Dream-Support
wenig Feedback zu diesem Problem. Den letzten Bootlog 2*Boot ohne Festplatte und DVD hänge ich an.

Viele Grüße,
prtigger