Am zweiten Tag mit deaktivierten jffs2, kein Boothänger!
8000 bootet aus DeepStandby nicht immer OE2.0 - Bootlog anbei
-
-
Heute Nacht fuhr die Box nicht runter, und da schon so spät war, hab ich Netztschalter gekillt.
Heute Morgen blieb sie dann bei 50% wieder hängen.
-
Ja ohne den Netzschalter wäre das Leben mit unseren Linux Boxen sehr schwer!
-
Ja aber genau das macht mir beim Multibooten das Leben immer schwer wenn Ihr damit die Filesysteme versaut. Aber das gehört nicht hier her.
Das jffs2 ist allerdings so designed das es nicht kaputt gehen sollte durch abdrehen oder unsaubereres umount, wobei der jffs2 summary patch eben experiementell ist und für den muss das nicht gelten, daher ja auch meine Bitte es mal ohne auzuprobieren, auch wenn die Chance nur gering ist dass es was bringt. Wobei der jffs2 Summary eben nur bei 7020hd und 8000 verwendet wird, und erstere hat ganz andere Flashchips und controller.
-
Gerade nach nochmal nach ein par Stunden gebootet und lief wieder sauber durch, bin schon gespannt wie es weitergeht, schaut aber schon so aus als wäre der hänger jetzt weg denn vor dem Test mit jffs2 deaktivieren gestern und heute hatte ich tägliche Boothänger!
-
Wenn wir Probleme mit JFFS2 haben, dann können wir Ubifs einsetzen.
Cau Adas
-
MIt deaktiviertem jffs2 ist auch nix ander als aktiviert, also nix von 30-60 sec längere Bootzeit eher nur 5 sec!
-
Ihr habt nicht jffs2 deaktiviert, sondern das jffs2 Summary
Und es hängt davon ab wie voll Euer Image ist wie stark sich die Bootzeit verlängert, aber wenn du sagst die bootzeit ist praktisch ident dann kann es sein das der jffs2 summary sich schon auf invalid gesetzt hat selbst wenn es aktiv war.
Und ich glaube nicht das uns DMM das ubifs aufdreht (ist eh schon lange im Kernel), weil sie dafür neuen Loader brauchen würden und wir kriegen ziemlich sicher sowieso bald eine Runde neue Loader um die derzeit schon an jeder Ecke angebotenen kopierten SIMS auszuschließen mit denen du auch auf Kloneboxen jedes aktuelle Image (auch OE 2.0) ungepatched booten kannst.
Und ich glaube nicht das DMM sich traut beides gleichzeitg zu ändern, schon weil auf den boxen mit 64MB Flash das ubifs den Platz sprengen würde womit es nur auf der 8000 und 7020hd funktionieren wurde und da ubifs mehr memory braucht würde es der 8000 auch nicht wirklich gut tun, insofern ist das keine Lösung vermute ich mal. Da ist die Lösung einen USB oder besser SATA Stick zu kaufen und von dort zu booten noch die elegantere, weil billig und Soforthilfe.
-
Die Boot zeit hat sich um etwa knapp 10 sec verlängert!
-
Für ein frisch gesflaschtes Image wo kaum was verändert wurde und du keinen Softwareupdate gemacht hast der den Flash zerfleddert ist das durchaus möglich das es nicht mehr ist.
Aber wenn es so wenig ist kann man es durchaus auch länger dauer testen, wobei es durchaus sein kann das du das Problem genauso bekommst, aber das ist ja das lustige am Testen das man am System was verändert und schaut wie es sich verhält und daraus seine Schlüsse zieht.
PS: Wenn du wirklich langsam booten willst musst du nur das mkfs.jffs2 mit compression none laufen lassen, die Images sind dann deutlich größer und booten seeeehr langsam. Aber diese Einstellmöglichkeit ist im dFlash derzeit nicht aufgedreht.
PPS: Aber wir wollen nicht zu viele perverse Ideen auf einmal ausprobieren
-
Muss dazu sagen das ich men Image immer so klein wie möglich halte, ne dflash Sicherung hat bei mir nur 52 MB!
-
Na ja ein 'normales' OE 2.0 Experimental für die 8000er ist da schon fast doppelt so fett, aber das jffs2 Summary ist nicht umsonst auf den anderne Boxen wo alle images in der Größenordnung liegen (müssen damit sie in den Flash passen) nicht aufgedreht. Aber die Größe des Images reduziert höchsten die Wahrscheinlichkeit dass es auftritt würde ich mal vermuten.
PS: Und wenn es wirklich so ist das DMM eine Sicherung des Images helfen würde ein Filesystemproblem zu erkennen dann eher nur einen mit nanddump gemachte die alle Informationen im Flash so wie sie sind sichert, und offiziell gibt es sowas für die Dreambox ja gar nicht, vom Flashen von sowas mal ganz abgesehen
-
Tag drei fast vorbei und immernoch keine Boothänger
-
schön aber das würde Ghost wohl nur wirklich helfen den Fehler einzigrenzen wenn alle anderen auch konvertieren und dann keine Probleme mehr auftreten
-
Hi,
ehrlich gesagt glaube ich nicht, dass das überhaupt was bringt.. in dieser Form. Das Summary selber hat nichts mit uncorrectable errors zu tun....
Naja und anderes FS bringt auch nichts.. weil es wie gesagt nicht am FS selber liegt. Das Problem liegt wie schon beschrieben weiter unten... also vor dem FS.. die Fehler vom FS sind nur die Folge davon.
Wenn dem nicht so wäre, müssten ja die anderen Boxen auch betroffen sein. Und da gibts es das Problem nicht.
Aber wird schon werden.
cya
-
das jffs2 summary wird aber nicht von sooo vielen Boxen verwendet.
Es gibt aber mindestens 3 Leute die seitdem sie von einem SATA Stick Booten keine Hänger mehr beim Booten haben.
Das Problem ist das halt das Sitzen und warten für die User auch nicht sehr zufriedenstellend ist, und da kann man schon mal ausprobieren ob man es nicht auch mit Homöopathie wegbringt, auch wenn einem die Schulmedizin natürlich lieber wäre
-
das jffs2 summary wird aber nicht von sooo vielen Boxen verwendet.
Es gibt aber mindestens 3 Leute die seitdem sie von einem SATA Stick Booten keine Hänger mehr beim Booten haben.
Das Problem ist das halt das Sitzen und warten für die User auch nicht sehr zufriedenstellend ist, und da kann man schon mal ausprobieren ob man es nicht auch mit Homöopathie wegbringt, auch wenn einem die Schulmedizin natürlich lieber wäre
Ich glaube ja auch nicht das es wirklich und dauerhaft hilft - ausser uns die Wartezeit zu vertreiben.
-
Hi,
hmmm beim Studium der Logfiles ist mir eben was aufgefallen.
Also ich hab eine ganz doofe Vermutung... also es ist sehr Auffällig, dass immer wenn die uncorrectable errors auftreten kurz vorher der Treiber der Mini PCI Wlan Karte geladen wurde.. bzw.. die Initialisierung des Madwifi WLAN Treibers noch nicht beendet ist.
Also eine Idee wäre nun einfach mal aus "/lib/modules/3.2-dm8000/net" das ath_pci.ko zu entfernen .. also am besten per ftp auf dem PC sichern oder sowas.. oder mit dem mc auf der Box auf die HDD schieben.. auf jedenfall muss er aus /lib/modules raus.
Und dann mal ein paar Tage ohne das interne WLAN testen. Also der Treiber der WLAN Karte ist leider nicht sehr resourcen / timing freundlich. Also der blockiert leider sehr lang den Kernel. Und das ist während dem Flash zugriff dann tödlich. Oder kann tödlich sein.
Das könnte des Rätsels Lösung sein. Die Frage ist allerdings wie man das ganze dann lösen kann. Auf jedenfall wäre es erstmal einen Versuch Wert. Ist allerdings doof, weil die meisten werden wohl nur über WLAN Zugriff auf die Box haben. Vllt solange dann einen usb stick verwenden oder sowas.
cya
-
Ist das auch der Fall, wenn man W-Lan deaktiviert hat?
-
Meinst Du sowas, Ghost?
ZitatINIT: version 2.88 booting
Displaying bootlogo.
Starting udev
[ 5.936000] udevd[79]: starting version 182
[ 6.744000] ath_hal: module license 'Proprietary' taints kernel.
[ 6.750000] Disabling lock debugging due to kernel taint
[ 6.772000] ath_hal: 2009-05-08 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, REGOPS_FUNC, XR)
[ 7.111000] wlan: svn r3314
[ 7.377000] ath_pci: svn r3314
[ 7.381000] PCI: Enabling device 0000:00:01.0 (0000 -> 0002)
[ 7.387000] Atheros HAL provided by OpenWrt, DD-WRT and MakSat Technologies
[ 7.637000] uncorrectable error :
[ 7.641000] uncorrectable error :
[ 7.644000] mtd->read(0x584 bytes from 0x66ba7c) returned ECC error
[ 7.651000] JFFS2 notice: (110) read_dnode: wrong data CRC in data node at 0x0066ba7c: read 0x495d3c67, calculated 0x5729741.
[ 7.672000] uncorrectable error :
[ 7.675000] mtd->read(0x1f0 bytes from 0x666e10) returned ECC error
[ 7.706000] JFFS2 notice: (110) check_node_data: wrong data CRC in data node at 0x00666e10: read 0x12c29a60, calculated 0xf8911206.
[ 7.786000] fpga init
[ 8.210000] ath_rate_sample: 1.2 (svn r3314)
[ 8.239000] wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
[ 8.245000] wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
[ 8.256000] wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
[ 8.265000] wifi0: H/W encryption support: WEP AES AES_CCM TKIP
[ 8.458000] ath_pci: wifi0: Atheros 2413: mem=0xd0000000, irq=33
[ 10.320000] no done ack
[ 10.323000] no init ack
[ 10.326000] no init ack
[ 10.329000] no init ack
[ 10.332000] no init ack
[ 10.334000] Kernel panic - not syncing: cannot configure fpga!
[ 10.334000]
[ 10.342000] Rebooting in 180 seconds..