Von warten haben wir und Ghost aber nichts.
Wenn Euch fade ist - könntet Ihr mal wenn Ihr so eine Problembox habt mit dFlash eine Sicherung des Images machen und dabei in den Einstellungen vom dFlash das jffs2 Summary abdrehen (!) und dann so eine Sicherung flashen und die box ein paar mal rebooten um zu sehen ob es auch damit auftritt ?
Die Bootzeit wird dann zwar um ca. 30-60 Sekunden raufgehen (je nachdem wie voll Euer Flash ist) aber mich würde interessieren ob das einen Unterschied macht.
Hi,
ich würde wie gesagt gerne auch mal das bootlog sehen wenn die box dann sauber bootet. Und auch Bootlogs von anderen Leuten sind gerne Willkommen wo das Problem auftritt.. Nicht alle Boothänger haben die selbe Ursache. Das würde ich ungerne so pauschalisieren. Es bringt auch nichts wenn mir jemand sagt er hat auch das Problem und ist deshalb auf 1.6 zurück.. die Frage ist wann der letzte Versuch unternommen wurde. Es scheint ja bei einigen Leuten nun schon deutlich besser zu sein.
Debug im jffs2 Treiber wird nichts bringen. Denn damit ändert man das gesammte Timing. Außerdem ist jffs2 nicht die Ursache.. das Problem entsteht im darunter liegenden MTD layer schon.. also im Flash Zugriff.. jffs2 meckert dann als Folge davon.
Das größe Problem ist, dass das für mich überhaupt nicht nachstellbar ist. Also mit verschiedenen Boxen getestet. Also entweder es spielt irgendwie auch eine Rolle welche Festplatte verbaut ist, und oder welche USB / CF Karten noch gesteckt sind. Oder aber ob parallel irgendwelche nachinstallierten Tools / Treiber beim booten geladen werden. Das bringt mir alles sehr wenig. Vllt könnte es noch was bringen, wenn mir jemand mal ein NFI aus seinem installiertem Image erzeugt. Mit allem was da installiert ist. Dann könnte man das schonmal ausschliessen.
cu
Ja aber es muss dir doch der jffs2 treiber dann wenigstens zeigen bei welcher Art von IO auf welchem Block der dann vom mtd layer einen Fehler zurück kriegt ?
Weil das muss ja bei irgend einer Form von IO passieren ...
Und ich bin ziemlich sicher das Euch einer der User mit so einer Problembox diese gerne zusendet um das ganze zu reproduzieren wenn er dafür eine neue 7020HD als unbegrenzte Leihgabe bekommt ... bis das Problem gelöst ist.
Bei mir trat das Problem regelmäßig mit einem nackten Experimental-Image auf. Ich habe nur eine WD-Festplatte verbaut (WD10EADS), ansonsten steckt weder ein USB-Stick, noch eine CF-Karte.
Warum ich im Moment problemlos booten kann, verstehe ich selbst nicht.
Hi Ghost...,
werde morgen mal ohne CF und USB booten.
Ob diese Lücken auch da sind wenn die Box normal bootet, kann ich dir nicht sagen.
Aber ich hänge mal eine Log-datei von einem, nach einem abgebrochenen, "normalen" Bootvorgang an.
Seit den letzten drei oder vier Experimentals habe ich nie Updates gemacht, sondern immer das jeweilige Image frisch installiert,
kann aber am Wochenende nochmal das letzte Experimental frisch aufspielen.
Gruß TeHC
Na ja ab da geht es beim schiefgegangenen Boot los:
[ 80.095000] PCI: Enabling device 0000:00:01.0 (0000 -> 0002)
[ 80.101000] Atheros HAL provided by OpenWrt, DD-WRT and MakSat Technologies
[ 80.710000] uncorrectable error :
[ 80.714000] uncorrectable error :
[ 80.718000] mtd->read(0x474 bytes from 0x674b8c) returned ECC error
[ 80.725000] JFFS2 notice: (121) jffs2_get_inode_nodes: Node header CRC failed at 0x674b8c. {0899,0000,42dacbe1,0000028a}
[ 80.829000] ath_rate_sample: 1.2 (svn r3314)
Insofern dürfte Ghost schon recht haben, aber die Frage ist warum der Fehler nur manchmal auftritt. Und daher auch meine Frage ob Ihr mal das jffs2 OHNE summary fahren könnt, weil dann wird statt auf das beim umount geschriebene summary zu vertrauen beim mounten alles nochmals gescanned, was zwar länger dauert aber vielleicht am Verhalten was ändert.
Weil es kann sein das die Ursache schon vom unsauberem Runterfahren stammt und wir dann vielleicht an der falschen Stelle suchen.
PS: Ich habe mir beim Multiboot Image Runterfahren oft mein FAT und/oder mein ext3 gemorded und dann auch lange gesucht warum es dann manchmal anschließend nicht mehr booten wollte. Irgendwo im Board ist noch mein Feature request endlich ein zusätzlices sync ins umountfs reinzumachen - der übrigens bis heute nicht erhört wurde und das ich mir immer noch selber reinpatchen muss, aber das ist eine andere Geschichte.
Hallo,
die Probleme treten bei mir nur im Deep Standby und wenn die Box über den Netzschalter nach dem shutdown abgeschaltet wurde auf.
Ich habe aber den Eindruck das bevor dieser Fehler auftritt die Box länger beim herunterfahren braucht.
Sprich als wenn die Box nicht wirklich sauber heruntergefahren ist.
Auch wenn ich vorher Aufgenommene Filme gelöscht habe.
Dann braucht die Box einige Zeit und rödelt auf meiner WD10EADS Festplatte ewig bevor sie unten ist.
Displaying bootlogo.
Starting udev
[ 6.193000] udevd[83]: starting version 182
[ 7.681000] ath_hal: module license 'Proprietary' taints kernel.
[ 7.687000] Disabling lock debugging due to kernel taint
[ 7.710000] ath_hal: 2009-05-08 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, REGOPS_FUNC, XR)
[ 7.936000] wlan: svn r3314
[ 8.174000] ath_pci: svn r3314
[ 8.177000] PCI: Enabling device 0000:00:01.0 (0000 -> 0002)
[ 8.183000] Atheros HAL provided by OpenWrt, DD-WRT and MakSat Technologies
[ 8.644000] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[ 8.652000] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 8.883000] ath_rate_sample: 1.2 (svn r3314)
[ 8.903000] uncorrectable error :
[ 8.906000] uncorrectable error :
[ 8.910000] mtd->read(0xb3a bytes from 0x398ba0) returned ECC error
[ 8.917000] Data CRC e272e16f != calculated CRC 211cb0ac for node at 00398b5c
[ 8.937000] wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
[ 8.943000] wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
[ 8.954000] wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
[ 8.962000] wifi0: H/W encryption support:
[ 8.962000] uncorrectable error :
[ 8.963000] mtd->read(0x9b4 bytes from 0x379c58) returned ECC error
[ 8.963000] Data CRC bf582f44 != calculated CRC a8fe22ed for node at 00379c14
[ 8.963000] uncorrectable error :
[ 8.963000] mtd->read(0x44 bytes from 0x37a60c) returned ECC error
[ 8.993000] WEP AES AES_CCM TKIP
[ 9.055000] ath_pci: wifi0: Atheros 2413: mem=0xd0000000, irq=33
[ 9.324000] fpga init
[ 11.788000] done OK 0
[ 14.456000] enter base init, xvd 20100413, vdc 20100413, rap 20101005, xpt 20100825
[ 14.464000] !!! kernMemSize: 154 MB
mfg.
freeman
Edit: war quatsch...
Hi,
da ich die besagten Probleme auch hatte bzw habe, hab ich den Test-Kernel auch mal aufgespielt.
Hochgefahren ist die Box seitdem jedesmal, allerdings manuell gestartet, denn runterfahren geht jetzt garnicht mehr.
Sobald die Box durch ein Plugin oder mit der FB per "Ausschalten" runterfahren soll, hängt sie sich auf. Per SSH komme ich noch drauf und kann dort auch manuell den reboot anstoßen, dann gehts.
Hab jetzt den vorigen Kernel zurückgespielt, damit gehts wieder wie gehabt.
Keine Ahnung, ob das irgendwie für die Lösung relevant ist oder ob ich jetzt hier was ganz anderes habe.
Gruß,
Tanne
Edit: Das Problem war ein anderes: der nächtliche EPG-Refresh hat das Autotimer-plugin angestartet und da scheint es wohl ein Problem mit dem herunterfahren zu geben. Da ich das herunterfahren wieder aktivierte, als ich den neuen Kernel testete (um eben das hochfahren zu prüfen), dachte ich da an den Kernel.
Herunterfahren klappt jetzt aber sauber und ich teste den Kernel weiter...
Ich glaube DMM unterschätzt das Problem,bei mir ist das gleich wie bei Freeman.Ich denke es gibt viele 8K besitzer die die Box nie in den Deepstandbay bringen und dadurch auch keine Probleme haben.Mit einem log kann ich nicht (noch nicht) dienen da Tagsüber in gebrauch!
1. Fazit (weitere werden folgen)
Bei mir sind es jetzt mit neuem Kernel mehr Hänger, kann aber auch nur Zufall sein, schade das solche Hänger mich schon seit 10 Jahren immerwieder mal begleiten, angefangen mit der 7025, hoffe das die Jungs den Fehler entdecken, bisdahin versuche ich mal die Idee von GUTEMINE!
Hab jetzt den Tag lang mal Gutemines Vorschlag mit dem deaktivierten jffs dingens getestet und hatte bisher keine Hänger mehr!
Bei Laufendem Betrieb unter Tags wirst du auch keine Hänger haben, es geht darum ob die box sauber runterfährt und dann auch ohne komissche jffs2 Fehler wieder hochkommt.
Aber nach einem Tag oder einer handwoll reboots kannst du sowieso nichts sagen, also weitertesten, schon weil es ja nur ein Vorschlag war was man noch alles ausprobieren kann.
Frisch geflaschte images haben das problem ja scheinbar nicht, und es verschwindet durch reboot auch wieder, also muss es entweder daran liegen das was im Filesystem kaputt ist das sich wieder repariert oder das es als kaputt gemeldet wird obwohl es das nicht ist.
TeHC,
ich habe mir dein log mal angeschaut und dort ist auch ein CRC Fehler Eintrag drin:
Starting udev
[ 77.810000] udevd[86]: starting version 182
[ 78.768000] ath_hal: module license 'Proprietary' taints kernel.
[ 78.774000] Disabling lock debugging due to kernel taint
[
78.802000] ath_hal: 2009-05-08 (AR5210, AR5211, AR5212, AR5416, RF5111,
RF5112, RF2413, RF5413, RF2133, RF2425, REGOPS_FUNC, XR)
[ 79.254000] wlan: svn r3314
[ 79.497000] ath_pci: svn r3314
[ 79.501000] PCI: Enabling device 0000:00:01.0 (0000 -> 0002)
[ 79.507000] Atheros HAL provided by OpenWrt, DD-WRT and MakSat Technologies
[ 80.037000] Node CRC 5e7857a8 != calculated CRC d445adf8 for node at 007a3ad8
[ 80.654000] sched: RT throttling activated
[ 80.711000] ath_rate_sample: 1.2 (svn r3314)
[ 80.724000] wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
[ 80.730000] wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
[ 80.743000] wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
[ 80.752000] wifi0: H/W encryption support: WEP AES AES_CCM TKIP
[ 80.845000] fpga init
[ 80.871000] ath_pci: wifi0: Atheros 2413: mem=0xd0000000, irq=33
[ 83.328000] done OK 0
[ 87.058000] enter base init, xvd 20100413, vdc 20100413, rap 20101005, xpt 20100825
[ 87.066000] !!! kernMemSize: 154 MB
Also einwandfrei ist dass noch nicht.
Was meint Ghost dazu?
mfg.
freeman
Ich teste das schon logischer weise so wie es sein soll, denn nur Reboots hat ja keinen Sinn, ich mach die Box normal in den Deep und eben wenn wir sie nach ein par stunden brauchen dann wird sie gebootet, genau dann gibt es bei mir Boothänger, also nicht wenn man sie gerade runtergefahren hat sondern eher am nächsten Morgen oder eben am selben Tag nach nem beendeten Timer der sie dann runterfährt!
Hi,
ein JFFS2 CRC Fehler sagt erstmal nichts. Das kann schlimm sein.. muss aber nicht. Also das kann auch entstehen wenn die Box nicht sauber runtergefahren war.. oder was auch immer. Das ist erstmal nix wildes.
Schlimmer sind diese "uncorrectable errors" die aber eigentlich gar keine sind.. denn nach reboot geht es ja wieder. Das doofe / komische ist halt, dass ich das nicht wirklich nachstellen kann. Und ja anscheinen auch niemand sofort nachstellen kann. Das passiert ja anscheinend erst, wenn die Box lange im Deepstandby war. Was es natürlich dann sehr schwer macht irgendwie was zu debuggen.
Kann das hier denn jemand nachstellen nur dadurch, dass er die Box "kurz" in den Deepstandby schaltet?
Also bisher haben alle gesagt die Box muss über nacht aus sein.. oder mehrere Stunden.
Nochmal kurz zu der Aussage, dass DMM das Problem zu locker sieht. Was sollen wir tun. Wir können es nicht nachstellen. Und naja.. auf der anderen Seite tritt es ja auch nur in Experimental Images auf. Schlimmer wäre es, wenn es die Releases betreffen würde.
Und auf der anderen Seite wird die Box nicht mehr hergestellt. Was nicht heissen soll, dass wir das Problem nicht beheben möchten. Nur ist es halt nicht soo einfach.. Und mega viele Resourcen stehen da momentan auch nicht zur Verfügung.
Nichts desto trotz.. wenn ich es irgendwie schaffe nachzustellen werde ich es auch fixen..
cya
Hi,
so wie ich das sehe, hatten wir ein ähnliches Problem beim 1.6er Image. Das war damals ein Timing Problem und wurde beim Flash-Treiber gefixt.
Da gab es vorher eine Änderung beim Kernel. Es war auch nicht nötig die Box übernacht im Deep-Standby zu belassen. Einfach immer wieder Booten
und dann wieder runterfahren in Deep-Standby. So ungefähr 5-10mal hintereinander und die Box blieb stehen bei 50% boot. Ich schätze es gibt ein ähnliches
Problem auch beim 2.0 Image. Ich selbst setze zur Zeit aber das 1.6er Release ein.
Viele Grüße,
prtigger
Hi...,
also ich teste hier jetzt erst einmal eins nach dem anderen.
Im Moment heißt das, den letzten Kernel von Ghost ohne CF und ohne USB booten, und das
sollte mal eine Woche bis 10 Tage einwandfrei funktionieren.
Nur zur Info:
Bei reboots hatte ich das Problem noch nie, immer nur nachdem die Box längere Zeit (über Nacht) im Deepstandby war,
und auch dann nicht immer, nanchmal bootet sie dann ja auch durch.
Allerdings habe ich auch noch keine 10 reboots hintereinander gemacht bzw. getestet ob das Problem dann auch auftritt.
Festplatte bei mir im Moment eine Western Digital Green mit 2 TB, davor hatte ich eine WD Green mit 1 TB
Spätestens Montag werde ich das letzte Experimental nochmal frisch flashen.
Gruß TeHC
