Eraseblocks torture: OneNAND results
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<[email protected]>
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 atgit://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.
Signature · 2 lines
Best regards, Artem Bityutskiy (Битюцкий Артём)
Kyungmin,
Quoted 1 line · Kyungmin Park
Okay, I also try to test attached program for this weekend.
If you use it (which would _very_ be nice!), please, take the latest version from git. Also, take into account the following notes:
1. Although the documented eraseblock lifetime is about 100000, we started getting errors after about 6 million erase cycles. May be because our test is not torturous enough.
2. There is a "check" module option which is enabled by default. It slows the test down considerably. So I recommend to disable checking at first, run the test for, say 4 million erase cycles, then re-run it with checking enabled. So that you first screw up the eraseblocks, then you start checking data. There is a handy "cycles_count" option.
3. By default the test tortures 32 eraseblocks. You may configure this via a module parameter. Just glance inside of the torture.c.
Quoted 3 lines
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
Yeah, no idea. We didn't check that eraseblock contains all 0xFF bytes after erase. May be erase operation left some garbage? In the newer version we do check this.
Quoted 1 line
Anyway, I also ask the hardware team to check this problem.
Would be cool!
Quoted 1 line
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.
I will send you more data.
Quoted 1 line
If you have any issues or updated news. please let me know.
Sure.
P.S.: Test git: git://git.infradead.org/~dedekind/torture.git
Web snout for the Git tree:
http://git.infradead.org/?p=users/dedekind/torture.git;a=summary
Signature · 2 lines
Best regards, Artem Bityutskiy (Битюцкий Артём)
Quoted 1 line · Artem Bityutskiy
1. Although the documented eraseblock lifetime is about 100000, we started getting errors after about 6 million erase cycles. May be because our test is not torturous enough.
Isn't 100000 a figure quoted by the flash manufacturer to be the _minimum_ number of erase cycles, a specification which all devices must meet, even at extreme operating conditions (e.g. high temperature and extreme supply voltages)? That would imply that during more ordinary conditions, a random sample of flash chip would very likely be erasable many more times.
Another thing: Why implement it as a kernel module? Speed I would assume?
/Ricard
Hello Ricard,
Quoted 5 lines · Ricard Wanderlof
Isn't 100000 a figure quoted by the flash manufacturer to be the _minimum_ number of erase cycles, a specification which all devices must meet, even at extreme operating conditions (e.g. high temperature and extreme supply voltages)? That would imply that during more ordinary conditions, a random sample of flash chip would very likely be erasable many more times.
Probably. Not sure. Need to carefully look to the manual. Do not have it now handy. But probably you are right. Also HW guys say that such a very frequent erase may matter.
Quoted 1 line
Another thing: Why implement it as a kernel module? Speed I would assume?
Yeah, wanted to make it quicker.
Signature · 2 lines
Best regards, Artem Bityutskiy (Битюцкий Артём)