From: "Julianne C." <juliannerc@gmail.com>
To: linux-mtd <linux-mtd@lists.infradead.org>
Subject: OneNAND: Rate of write errors
Date: Wed, 21 Feb 2007 18:21:42 -0600 [thread overview]
Message-ID: <e167438e0702211621i2eadbf15s33db7c34dc989bb2@mail.gmail.com> (raw)
We are still struggling to understand and manage the OneNAND part on a
LogicPD PXA270 board. We are using the mtd development snapshot build
of 2-15-07 for the fs and device layers. Our requirements lead us to
use JFFS2 as the file system.
What we are seeing is that when we write to a file system that is
freshly erased and mounted using the command:
>mount -t jffs2 /dev/mtdblockx /mnt
and then performing some operation like tar or rsync to place files in
the new fs, we see about 5 to 8 "write errors" of the form per MB:
onenand_write: verify failed -74
Write of 2663 bytes at 0x007a6e14 failed. returned -74, retlen 0
Not marking the space at 0x007a6e14 as dirty because the flash driver
returned retlen zero
In further testing, we have replaced the memcmp function in
onenand_verify with a procedure that manually goes through the list,
and issues a printk statement for each bad byte it detects. Here is a
sample of the bad bytes we see:
Cmp failed [1596] eb 00
Cmp failed [1594] e6 9f
Cmp failed [1954] 7b 4d
Cmp failed [1654] ae 00
Cmp failed [1972] 82 00
Cmp failed [462] d3 00
Cmp failed [972] a7 26
Cmp failed [1242] d8 8d
Cmp failed [54] 6e a0
Cmp failed [824] 3a 56
Cmp failed [1360] 78 67
Cmp failed [1584] 82 00
Cmp failed [1376] 00 5a
Cmp failed [64] 3f 00
Cmp failed [444] 90 e5
Cmp failed [310] 94 2d
Cmp failed [1764] 7a 04
Cmp failed [1030] f8 14
Cmp failed [68] 1e 72
Cmp failed [1910] de 01
Cmp failed [780] 37 00
Cmp failed [1536] 76 00
Cmp failed [1064] 2c 00
Cmp failed [644] 58 00
Cmp failed [1428] 25 00
Cmp failed [440] 89 00
Cmp failed [1852] 6d 00
where the first byte is the expected buffer value, while the second is
what is actually seen, and the value in the brackets is the index in
the 2048 byte array being tested.
These values were accumulated over about 4 MB of writes to the fs.
Is this common to see this many errors in that amount of page writes?
If not, are there adjustments that can be made to the device setup to
help reduce these errors?
next reply other threads:[~2007-02-22 0:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-22 0:21 Julianne C. [this message]
2007-02-22 9:28 ` OneNAND: Rate of write errors Adrian Hunter
-- strict thread matches above, loose matches on Subject: below --
2007-02-22 16:35 Julianne C.
2007-02-23 8:04 ` Adrian Hunter
2007-02-26 0:41 ` Kyungmin Park
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=e167438e0702211621i2eadbf15s33db7c34dc989bb2@mail.gmail.com \
--to=juliannerc@gmail.com \
--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