From: Artem Bityutskiy <dedekind@infradead.org>
To: Kyungmin Park <kyungmin.park@samsung.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Eraseblocks torture: OneNAND results
Date: Thu, 07 Dec 2006 16:30:03 +0200 [thread overview]
Message-ID: <1165501803.20337.97.camel@sauron> (raw)
[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]
Hello Kyungmin,
We have a test board with KFN2G16Q2M 256MiB OneNAND. We decided to write
a torture test which will torture few eraseblocks just in order to see
what happens.
We wrote a small test program which basically erases several eraseblocks
in a cycle till it gets an error. The test program is attached
(torture.git.tar.bz2), and it is also available at
git://git.infradead.org/~dedekind/torture.git.
By default the program does the following:
1. Erases an eraseblock. Reads it back and makes sure there are only
0xFF bytes.
2. Writes 0x55/0xAA pattern. In case of NAND we store 0x55 at one page,
0xAA at the next and so on. Each next erase we switch 0x55 and 0xAA
bytes.
3. Read the eraseblock back and make sure we read the same data.
And so on till an error occurs. Of course we check return codes.
The reason for this test is just because we are curious how our OneNAND
setup behaves in case of worn-out eraseblocks.
We have got kind of strange result. What we have is that after several
million erase cycles we start reading incorrect data back. Sometimes
there are one-bit errors, sometimes many-byte errors. We do not get any
error code from mtd->read(). We do not see single-bit errors corrected.
mtd->write() and mtd->erase() functions do not return any error as well.
Kyungmin, did you do any kind of tests like this? I offer you to try our
test too.
Other people may also try to wear-out few eraseblocks on their devices
and see what happens. Then for example, mount JFFS2 and see what it
says/does.
But please, beware, the test may damage your system so run it only if
you know exactly what you do. Authors are not responsible for any
damaged caused by this test.
----------------------------------------------------------------
[54592.767700] EB torture: Page 0 has 4 bytes/16 bits failing verify,
starting at offset 0x1c
[54592.776214] Offset Read Written
[54592.781860] 0x018: aa aa aa aa 00 00 00 00 *** aa aa aa aa aa aa
aa aa
[54592.789123] 0x020: aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa
----------------------------------------------------------------
[90073.926055] EB torture: Page 0 has 20 bytes/160 bits failing verify,
starting at offset 0xc
[90073.934661] Offset Read Written
[90073.940490] 0x008: 55 55 55 55 aa aa aa aa *** 55 55 55 55 55 55
55 55
[90073.947784] 0x010: aa aa aa aa aa aa aa aa *** 55 55 55 55 55 55
55 55
[90073.954895] 0x018: aa aa aa aa aa aa aa aa *** 55 55 55 55 55 55
55 55
[90073.962158] 0x020: 55 55 55 55 55 55 55 55 55 55 55 55 55 55
55 55
----------------------------------------------------------------
Below go some examples of test failures.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
[-- Attachment #2: torture.git.tar.bz2 --]
[-- Type: application/x-bzip-compressed-tar, Size: 13108 bytes --]
next reply other threads:[~2006-12-07 14:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-07 14:30 Artem Bityutskiy [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-12-08 2:00 Eraseblocks torture: OneNAND results Kyungmin Park
2006-12-08 6:19 ` Artem Bityutskiy
2006-12-08 13:43 ` Ricard Wanderlof
2006-12-08 13:52 ` Artem Bityutskiy
2006-12-08 7:42 Kyungmin Park
2006-12-08 8:08 ` Artem Bityutskiy
2006-12-08 13:30 ` Artem Bityutskiy
2006-12-11 8:31 Kyungmin Park
2006-12-13 13:46 ` Artem Bityutskiy
2006-12-15 5:02 Kyungmin Park
2006-12-15 7:54 ` Enrico Migliore
2006-12-15 8:44 ` Ricard Wanderlof
2006-12-21 15:30 ` Jarkko Lavinen
2006-12-22 7:58 Kyungmin Park
2006-12-22 9:22 ` 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=1165501803.20337.97.camel@sauron \
--to=dedekind@infradead.org \
--cc=kyungmin.park@samsung.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