Hello,

I have read your post about JFFS2 CRC and ECC problems. I have the same problem: deep standby for a few hours and I have already ECC problems on the first boot. A few reboots and the ECC are gone. (I 'solved' it myself with a workaround script to grep on ECC at boot time and initiate a reboot if ECC detected). I mailed support from dream multimedia and they proposed to rma the box as ECC are Flash memory errors. So this month my box will go back for repair.

For this reason, I'm investigating if it is possible to not boot anymore from internal flash but from CF or USB. If my CF or usb wears out, just put in a new stick or card.

Hi,

I modified the /usr/bin/enigma2.sh to reboot the server when "dmesg" reports CRC problems :

I do not have my scripts with me for the moment. but this could help:

dmesg > /media/hdd/movie/dmesg.out

grep CRC /media/hdd/movie/dmesg.out
ret=$?
if [ $ret -eq 0 ] ; then
/sbin/reboot
fi

as long as there is CRC errors detected the device will reboot itself. My device reboots itself once after a deep standby.(but this can perhaps vary). But after a reboot when there are no more CRC errors , enigma starts up correctly.

Another workaround is to buy a usb stick, and boot from usb. (in bios it is possible to config primary boot source first usb and then flash if usb is not found). but you have some work to get the usb stick working. I'm going this way to prevent much writes in the nand flash, but my solution is not yet 100% working. (when my usb stick has worn out, just put a new one in.)

I fear that the nand flash wears out quickly, but I may be wrong. anyway, this month my dm8000 will be returned for RMA fixing. (I hope I'll get back my device within reasonable time)

by the way, I'm running openpli. not sure if this is OE 1.6 based. Do you have an image 1.5 based? So I can make a test? DM confirmed me that ECC problems are hardware related?

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

Thanks for the info. I'll make some time to try out the 2.8.4 release sooner or later and hope to see the same effects so I can also be sure that it is software related. (that will keep me off from worrying)

In the mean time, a simple way to boot from usb (stick of 2GB is more than enough) is :
format a usb stick with 2 partitions :
- first partition : vfat around 100MB is sufficient. In there you place autoexec.bat wich includes the same lines as you find in /boot but you have to change root to root=/dev/sdc2 and change rootfstype=ext3
and add panic=10 (details can be found when googling for linux kernel parameters). Copy all the files of /boot from your dreambox on this partition(be carefull about symlinks, they are not supported in vfat, so you have to place there the real files)

- second partition : ext3, make it 512MB or higher, but you can disable (with command chattr -R +A and chattr -R -j) journalling, access-time logging. In there you copy the whole / (root tree) that you have on your dreambox. But you must leave /dev, /autofs, /proc , /sys, /var empty. You don't need to copy /boot as it is copied on the first partition.

- In /etc/fstab comment out the lines that mount mtdblock2, mtdblock3 (as this is flash, and not needed when booting from usb)

In the second stage loader you must set the first boot source to usb and second to flash.

When there is no compact flash and sd-card inserted, your usb stick (only one inserted) will be seen by the kernel as sdc. (thats why you need to mention rootfs=/dev/sdc2)

This way, your receiver will run perfectly and the internal flash is only once used at boot time (the second stage loader is used to jump directly to usb). No jffs2 errors anymore as there are no jffs2 partitions used in this config.

My stick (sandisk cruzer blade) is working fine now. The boot process is much quicker as ext3 filesystem takes much less time to mount than a JFFS2 filesystem.

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

Hallo,

probiert bitte mal die experimental-images vom 15.01.2011 bzw den aktuellen vom 17.01.2011.

Bei mir sieht es seit dem 15.01.2011 bis jetzt ganz gut aus.

Jedenfalls geibt es nach dem Flashen keine Bootschleife mehr und keine CRC errors.

Bislang auch noch keine executive main Schleife ("50% Balken, danach kein OLED nur blaue LED").

Aufnahmen laufen nur aus dem Deep Standby.

Bisher noch keine Hänger.

Abwarten und Teetrinken.

mfg.

freeman

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

Kann mich freeman ("probiert bitte mal die experimental-images vom 15.01.2011 bzw den aktuellen vom 17.01.2011") nur anschließen. Bei mir laufen zwei dm8000 komplett fehlerfrei damit.

Mit den Releases hatte ich oft mehr Probleme als mit den Experimentals. Die Lösung eines Release Problems kann ja frühestens mit dem nächsten Release erfolgen, das evtl. eine Zeit lang auf sich warten lässt. Das alte Release wird ja nicht für euch "repariert" werden. Ihr müsstet euch also das alte Release für eine lange Zeit mit einem Workaround "zurecht biegen".

Warum sollte man sich umständlich mit einem Workaround behelfen nur, damit ein Release vernünftig auf der eigenen Box läuft?

Warum auf eine Antwort von Herrn Teuser warten?
Wenn es mit einem Experimental keine Besserung geben sollte, könnt ihr doch immer noch ein Release einfach wieder drüber flashen. Geflasht ist in fünf Minuten. Hat man zuvor eine Sicherung erstellt, braucht man vielleicht noch 15 Minuten um ein paar Plugins neu auf die Kiste zu laden. Jedenfalls dauert alles ca. 30 Minuten und mit etwas Glück hat man ein Problem weniger.

Falls das Experimental läuft, aber immer noch einen Fehler hat, könnte man diesen auch hier im Forum melden und darum bitten, dass er beseitigt wird.
Davon hätten dann alle Dreambox User etwas und nicht nur einzelne, die sich eine eigene Lösung stricken .
(Ich hoffe ja für euch, dass nicht wirklich ein Hardwarefehler vorliegt. )

Welche Probleme auch immer meine beiden dm8000er (unterschiedliche Modellreihen, Festplatten, Slimline DVDBrenner) mit einer Exp. Firmware hatten, sie wurden immer nach Diskussion hier im Forum gelöst.
Der Vorteil ist: Die Lösung ist im Image eingebaut und muss nicht jedes Mal von Hand nachinstalliert werden.

Ausnahmen bei mir: 1. NTFS Support für externe USB Festplatten / 2. Unterstützung zum Abspielen kopiergeschützter DVDs. Beides muss bei Bedarf manuell nachgerüstet werden.
1. (NTFS Lese Support) sollte demnächst mal bitte fest im Image eingebaut werden.
2. wird aus lizenzrechtlichen Gründen verständlicherweise wohl nie eingebaut werden.

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,

ich musste leider feststellen das die Software Update Funktion immernoch Probleme bereitet.

Seit Dezember 2010 habe ich hier Probleme.

Softwarepakete werden upgedatet und nach einem Neustart bleibt die Kiste bei 50% balken executive main hängen.

Bitte Bitte an die Kollegen Andreas Monzer und Andreas Oberritter schaut euch die devconfig den Nandflashtreiber und die Updatescripts bitte nochmal an.

Der Release 3.0.3 lässt sich nicht ohne Greenscreen und Bootschleife flashen und die Box bleibt aus dem Deep Standby alle 2-3 Mal hängen.

Hier hat sich aus meiner Sicht ein schwerwiegender Softwarefehler eingeschlichen.

mfg.

freeman

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,

mittlerweile habe ich mit dem Release 3.0.3 so viel Probleme die leider sich durch die Experimental Stages auch durchziehen.

Mein Problem habe ich auch wie prtigger an die Entwicklung über Herrn Teuser weitergegeben.

An Ghost wann wird der aktuelle kernel 2.6.18-r8.0 mit seinen Treibern einzughalten.

Etwas irretierend finde ich es auch das laut kernel.org ein entsprechender mtd-patch erst in Verbindung mit kernel 2.6.21-rc7 realisiert wurde.

Sprich ein geeigneter Algorithmus für das JFFS2 in der Version 2.2 programmiert wurde um solche Fehlerhaften Cache Einträge wie wir sie manchmal haben zu vermeiden.

Der Patch identifiziert eindeutig den verwendeten NAND-FLASH-Speicher:

Auszug git-mtd.patch:

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 9752388..cf197ad 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -431,6 +431,7 @@ #define NAND_MFR_NATIONAL 0x8f
#define NAND_MFR_RENESAS 0x07
#define NAND_MFR_STMICRO 0x20
#define NAND_MFR_HYNIX 0xad
+#define NAND_MFR_MICRON 0x2c

/**
* struct nand_flash_dev - NAND Flash Device ID Structure

Und jetzt schaut euch mal euer Bootlog an Auszug:

[4294670.387000] - NAND PROBE: 2c da 80 15
[4294670.390000] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Unknown NAND 256MiB 3,3V 8-bit)
[4294670.398000] Scanning device for bad blocks
[4294670.404000] Bad eraseblock 114 at 0x00e40000
[4294670.416000] Bad eraseblock 347 at 0x02b60000
[4294670.437000] Bad eraseblock 846 at 0x069c0000
[4294670.465000] Bad eraseblock 1540 at 0x0c080000
[4294670.487000] Creating 7 MTD partitions on "NAND 256MiB 3,3V 8-bit":
[4294670.493000] 0x0000000000000000-0x0000000010000000 : "complete"
[4294670.498000] 0x0000000000000000-0x0000000000100000 : "loader"
[4294670.504000] 0x0000000000100000-0x0000000000400000 : "boot partition"
[4294670.510000] 0x0000000000400000-0x0000000004000000 : "root partition"
[4294670.516000] 0x0000000004000000-0x0000000008000000 : "home partition"
[4294670.521000] 0x0000000008000000-0x000000000f800000 : "unused partition"
[4294670.528000] 0x000000000f800000-0x0000000010000000 : "preset partition"

Normalerweise sollte die Zeile so oder so ähnlich aussehen:

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit)

Ich hoffe mir ist jetzt keiner Böse, wenn ich sage das hier möglicherweise der Verdacht naheliegt minderwertige NAND-FLASH-Bausteine verwendet zu haben.

Ferner man Anhand des Verwendeten NAND Flash PART NUMBERING schon Bausteine mit BAD BLOCK Kennzeichung verwendet:

B : Included Bad Block
S : 1~5 Bad Block Included
P : All Good Block

Das sollte bei einer 1000€ Box nicht sein.

Aber vielleicht ist Dream auch den NAND-FLASH-Speicher Fälschern auf den Leim gegangen.

Diese sind momentan sehr stark im Umlauf laut Aussage von IBM und Intel.

Sie werden überweigend in China produziert.

Ich hoffe das hier jemand aus der Entwicklung mitliest.

Vielleicht hat aus dem Forum jemand noch eine Idee oder Anregung.

mfg.

freeman

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 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 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

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