Eraseblocks torture: OneNAND results

[Artem Bityutskiy]

Kyungmin,

On Fri, 2006-12-08 at 02:00 +0000, Kyungmin Park wrote:
> 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.

> 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.

> Anyway, I also ask the hardware team to check this problem.
Would be cool!

> 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.

> 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

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)