Re: [PATCH] mtd: Add simple read disturb test

[Andrea Scian <rnd4@dave-tech.it>]

Hi all,

Il 02/04/2015 18:18, Richard Weinberger ha scritto:
> Am 02.04.2015 um 18:04 schrieb Brian Norris:
>> On Thu, Apr 02, 2015 at 04:13:46PM +0200, Richard Weinberger wrote:
>> [1] Although there are some latent issues in these tests that are still
>> getting get worked out (e.g., bad handling of 64-bit casting; too large
>> of stacks; uninterruptibility). The latter two would not even exist if
>> we were in user space.
> 
> uninterruptibility got solved by my "[PATCH] mtd: Make MTD tests cancelable" patch.

And this is something I was looking for from years!

> But if we want to kill drivers/mtd/tests/ I'll happily help out.
> Where shall we move these tests into? mtd-utils?

I think so.
I'm writing a similar read disturb test on my own, mixing already
existing mtd-tools (flash_erase, nandwrite, nanddump) with some naive
bash scripting.
IMHO, we have a lot of pros running in userspace:
* dumping data
* better error/status log (which can be easily written on file, for
example, while mtdtests error log is mixed with other kernel messages)
* running test in parallel (if it make sense ;-)

For example on read disturb I already calculate RBER, which is, AFAIK, a
nice index on the quality of the NAND cell and of its data. I'm working
on writing down data on a separate CSV which can be easily processed
later (e.g. to make part to part comparison/statistics).

There's already a test directory inside mtd-utils, I think it's better
to start creating tests there, as userspace tools, whenever this is
possible.
Do we have any reason to have MTD tests as kernel module? (performance?)

Kind Regards,

-- 

Andrea SCIAN

DAVE Embedded Systems