Eraseblocks torture: OneNAND results

Kyungmin Park kyungmin.park at samsung.com
Thu Dec 7 21:00:11 EST 2006


Hi Artem,

Okay, I also try to test attached program for this weekend.

However, I have a question
There's some strange pattern in log.
In any case. it can't occur from 0xaa(0b1010) to 0x55(0b0101) since it's impossible to change from 0 to 1 even though it's possible from 1 to 0

Anyway, I also ask the hardware team to check this problem.

And also could you send the chip dump data to me? since it takes a long time to worn-out. I first analyze the worn-out chip data.

If you have any issues or updated news. please let me know. 

Thank you,
Kyungmin Park

------- Original Message -------
Sender : Artem Bityutskiy<dedekind at infradead.org> 
Date   : Dec 07, 2006 23:30
Title  : Eraseblocks torture: OneNAND results

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 (Битюцкий Артём)


More information about the linux-mtd mailing list