public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Michal Ludvig <mludvig@logix.net.nz>
To: dedekind@infradead.org
Cc: linux-mtd@lists.infradead.org
Subject: Re: nandwrite/ubi memory corruption?
Date: Fri, 17 Oct 2008 11:10:09 +1300	[thread overview]
Message-ID: <48F7BBC1.8090804@logix.net.nz> (raw)
In-Reply-To: <1224168977.4466.4.camel@sauron>

Artem Bityutskiy wrote:
> On Thu, 2008-10-16 at 17:49 +0300, Artem Bityutskiy wrote:
>> On Thu, 2008-10-16 at 23:10 +1300, Michal Ludvig wrote:
>>> Hi all,
>>>
>>> I've got an ARM board with 64MB of NAND flash with 3 logical partitions
>>> and am experiencing (probably) memory corruption of UBI/UBIFS on
>>> /dev/mtd2 after writing data with nandwrite to /dev/mtd1.
>>>
>>> These are my logical partitions on NAND:
>>> [...]
>>>
>>> ~ # ls
>>> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
>>> 2414:15360, written 0 bytes
>>> UBI warning: ubi_eba_write_leb: failed to write data to PEB 2414
>>> UBI: recover PEB 2414, move data to PEB 2428
>>> UBI warning: ubi_io_read_vid_hdr: bad magic number at PEB 2414: 00000000
>>> instead of 55424921
>>> UBI warning: ubi_ro_mode: switch to read-only mode
>>> UBIFS error (pid 224): ubifs_wbuf_sync_nolock: cannot write 512 bytes to
>>> LEB 746:14336
>>> UBIFS error (pid 224): ubifs_bg_wbufs_sync: cannot sync write-buffer,
>>> error -5
>>> UBIFS warning (pid 224): ubifs_ro_mode: switched to read-only mode, error -5
>> Could you please try ubiformat instead of nandwrite? 

~ # ubiformat /dev/mtd1 -v
ubiformat: mtd1 (NAND), size 1900544 bytes (1.8 MiB), 16384 eraseblocks
of 16384 bytes (16.0 KiB), min. I/O size 512 bytes
libscan: start scanning eraseblocks 0-116
libscan: scanning eraseblock 0: alien
libscan: scanning eraseblock 1: alien
[...]
libscan: scanning eraseblock 90: alien
libscan: scanning eraseblock 91: alien
libscan: scanning eraseblock 92: empty
libscan: scanning eraseblock 93: empty


[...]
libscan: scanning eraseblock 115: empty
libscan: finished, mean EC 0, 0 OK, 0 corrupted, 24 empty, 92 alien, bad 0
ubiformat: 24 eraseblocks are supposedly empty
ubiformat: warning!: 92 of 116 eraseblocks contain non-ubifs data
ubiformat: continue? (yes/no)  yes
ubiformat: warning!: only 0 of 116 eraseblocks have valid erase counter
ubiformat: erase counter 0 will be used for all eraseblocks
ubiformat: note, arbitrary erase counter value may be specified using -e
option
ubiformat: continue? (yes/no)  yes
ubiformat: use erase counter 0 for all eraseblocks
ubiformat: eraseblock 0: erase, do not write EC, leave for vtbl
ubiformat: eraseblock 1: erase, do not write EC, leave for vtbl
ubiformat: eraseblock 2: erase, write EC 0
ubiformat: eraseblock 3: erase, write EC 0


[...]
ubiformat: eraseblock 115: erase, write EC 0
ubiformat: write volume table to eraseblocks 0 and 1
~ #

Nothing was apparently broken after ubiformat, system kept running
smoothly. But I can't use ubiformat for writing kernel image, can I?

Is there any other way to write raw kernel image to /dev/mtd1 other than
using nandwrite?

> Also, please, give me your page and sub-page size. 

UBI: attaching mtd2 to ubi0
UBI: physical eraseblock size:   16384 bytes (16 KiB)
UBI: logical eraseblock size:    15360 bytes
UBI: smallest flash I/O unit:    512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                1024
UBI: attached mtd2 to ubi0
UBI: MTD device name:            "ubi"
UBI: MTD device size:            61 MiB
UBI: number of good PEBs:        3960
UBI: number of bad PEBs:         0
UBI: max. allowed volumes:       89
UBI: wear-leveling threshold:    256
UBI: number of internal volumes: 1
UBI: number of user volumes:     1
UBI: available PEBs:             2054
UBI: total number of reserved PEBs: 1906
UBI: number of PEBs reserved for bad PEB handling: 195
UBI: max/mean erase counter: 4/0

Michal

  reply	other threads:[~2008-10-16 22:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-16 10:10 nandwrite/ubi memory corruption? Michal Ludvig
2008-10-16 14:49 ` Artem Bityutskiy
2008-10-16 14:56   ` Artem Bityutskiy
2008-10-16 22:10     ` Michal Ludvig [this message]
2008-10-17 11:02       ` Artem Bityutskiy
2008-10-17 12:09         ` Artem Bityutskiy
2008-10-18 20:34           ` Michal Ludvig
2008-10-17 12:06       ` Artem Bityutskiy
2008-10-16 15:01 ` Ben Dooks
2008-10-16 21:43   ` Michal Ludvig
2008-10-16 21:56     ` Ben Dooks
2008-10-16 23:01       ` Michal Ludvig
2008-10-17  2:06         ` Michal Ludvig
2008-10-17 11:03       ` Artem Bityutskiy
2008-10-17 13:42         ` Ben Dooks
2008-10-17 13:44           ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48F7BBC1.8090804@logix.net.nz \
    --to=mludvig@logix.net.nz \
    --cc=dedekind@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox