Thema: Duo2: Wie Flashspeicher prüfen - vermutlich teilweise defekt

Heute konnte meine Duo2 nicht mehr fertig booten. Nachdem ich nach den Fehlermeldungen suchte, ergab sich, dass der Speicher vermutlich nicht mehr beschreibbar war. Auf die Box konnte ich aber noch in einer Shell zugreifen. Ich habe neu geflasht und es läuft wieder. Damit ist das Problem aber nicht erledigt, die Box ist ziemlich neu und wenn, dann wiill ich möglichst bald reklamieren.

Auszug aus den Fehlermeldungen:

Code:

# dmesg
00001700: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff  ................................
...
00001b00: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff  ................................
00001b20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff        ..............................
UBIFS error (pid 57): ubifs_scan: LEB 7700 scanning failed
UBIFS error (pid 57): do_commit: commit failed, error -135
UBIFS warning (pid 57): ubifs_ro_mode: switched to read-only mode, error -135
CPU: 0 PID: 57 Comm: ubifs_bgt0_0 Tainted: P           O 3.13.5 #1
UBIFS error (pid 710): make_reservation: cannot reserve 569 bytes in jhead 2, error -30
UBIFS error (pid 710): do_writepage: cannot write page 157 of inode 25609, error -30
Stack : 00000001 807b0000 00000000 00000000 00000000 00000000 808266ea 00000042
      00000000 00000039 00000000 807a0000 807a6667 cfe3cb10 806ff7d4 00000039
      00000000 80823818 00000002 cfe54920 cfc336a0 8065726c 00000000 8002d64c
      219c4000 00000000 807040d8 cf4bfdb4 cf4bfdb4 807a0000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 cf4bfd30
      ...
Call Trace:
[<8000c53c>] show_stack+0x64/0x7c
[<80657dec>] dump_stack+0xc8/0xfc
[<802a59cc>] do_commit+0x5e0/0x5e8
[<802a5bc0>] ubifs_bg_thread+0x1ec/0x218
[<8004faa4>] kthread+0x10c/0x124
[<80006ac8>] ret_from_kernel_thread+0x14/0x1c

UBIFS error (pid 56): make_reservation: cannot reserve 160 bytes in jhead 1, error -30
UBIFS error (pid 56): ubifs_write_inode: can't write inode 25609, error -30
[AUD]: AUDIO_SET_MUTE 0 
[AUD]: AUDIO_SET_MIXER -832823824 
[AUD]: AUDIO_SET_MIXER : amixl 0, amixr 0
[AUD]: AUDIO_SET_MIXER : next left volume 0, right volume 0
[AUD]: AUDIO_SET_MIXER : next left volume -70, right volume -70
[AUD]: AUDIO_SET_MIXER -832823824 
[AUD]: AUDIO_SET_MIXER : amixl 0, amixr 0
[AUD]: AUDIO_SET_MIXER : next left volume -70, right volume -70
[AUD]: AUDIO_SET_MIXER : next left volume -70, right volume -70
UBIFS error (pid 56): make_reservation: cannot reserve 160 bytes in jhead 1, error -30
UBIFS error (pid 56): ubifs_write_inode: can't write inode 25609, error -30
UBIFS error (pid 56): make_reservation: cannot reserve 160 bytes in jhead 1, error -30
UBIFS error (pid 56): ubifs_write_inode: can't write inode 9881, error -30
UBIFS error (pid 56): make_reservation: cannot reserve 160 bytes in jhead 1, error -30
...
UBIFS error (pid 56): ubifs_write_inode: can't write inode 25609, error -30
UBIFS error (pid 56): make_reservation: cannot reserve 160 bytes in jhead 1, error -30
UBIFS error (pid 56): ubifs_write_inode

Wie kann ich testen, ob der Flashspeicher fehlerhaft ist?

Was mich nervt, ist, dass die Box plötzlich unerklärlich einfriert. Ich besten Fall kann ich die Box per ssh runterfahren, im schlechtesten Fall bleibt nur der Netzschalter. Ich flashe bei jedem Absturz neu und konfiguriere dann neu, dh ich sicher nicht irgendetwas fehlerhaftes zurück.

Was sich ändert, sind die Einträge in dmesg in der Art

Code:

nand_read_bbt: bad block at 0x

Anfangs waren es 2, jetzt sind es 8.

Selbst neu ausgelieferte Flash-Chips können und dürfen ein paar Bad-Blocks haben

Sind 8 bereits zu viel?

Bedeutet das also, dass ich mich weiter mit Abstürzen ärgern muss? Das passiert mit verschiedenen ROMs!

Erst wenn ca. 50% der Reserve-Blöcke

Was wären das bei der Duo2 ungefähr?

Ich verstehe auch noch nicht warum ich da Dateien anlegen kann, die mehrere GB haben. Ich glaube die Box hat doch 2GB Speicher, dh eine Datei mit 3GB sollte nicht möglich sein, oder?

Moin!

Eigentlich sollten beim Flaschen alle Bad Blocks markiert werden und somit keine Auswirkung haben.

Auch das die Anzahl ansteigt ist nicht unbedingt eine wahre Aussage, da es sehr wohl vorkommen kann, dass Blöcke fälschlicher Weise als bad markiert werden.
Bei den Dreams gibt es die Möglichkeit diesen Index zurück zusetzten. In wie weit dies bei Vu möglich ist kann ich nicht sagen.


Bei Dir sieht es aber eher danach aus dass das Dateisystem einen weg hat.

ubifs_write_inode: can't write inode 9881, error -30

Wenn das vor einer Sicherung schon so war, ist dies in der Image Sicherung ebenfalls vorhanden.

Du kannst also nur ein Problem bestätigen, wenn Du ein neues am besten originales Hersteller Image flashst und versuchst dann dort das Problem zu reproduzieren.

Übrigens, genau wegen sowas sollte man eine Linux Box nicht einfach abschalten.
Ist da noch ein Schreibvorgang im Gange, kann das Dateisystem sofort hinüber sein, aber erst später Auswirkungen zeigen.