From: Artem Bityutskiy <dedekind1@gmail.com>
To: Iwo Mergler <Iwo.Mergler@netcommwireless.com>,
Akinobu Mita <akinobu.mita@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: RE: [PATCH] Test for multi-bit error correction
Date: Mon, 03 Sep 2012 18:25:18 +0300 [thread overview]
Message-ID: <1346685918.3061.66.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <6871BC8982B258468985EE735D2C57524E269AFB60@ntcex01.corp.netcomm.com.au>
[-- Attachment #1: Type: text/plain, Size: 3686 bytes --]
On Fri, 2012-08-31 at 08:59 +1000, Iwo Mergler wrote:
> This tests ECC biterror recovery on a single NAND page. Mostly intended
> to test ECC hardware and low-level NAND driver.
>
> There are two test modes:
>
> 0 - artificially inserting bit errors until the ECC fails
> This is the default method and fairly quick. It should
> be independent of the quality of the FLASH.
>
> 1 - re-writing the same pattern repeatedly until the ECC fails.
> This method relies on the physics of NAND FLASH to eventually
> generate '0' bits if '1' has been written sufficient times. Depending
> on the NAND, the first bit errors will appear after 1000 or
> more writes and then will usually snowball, reaching the limits
> of the ECC quickly.
>
> The test stops after 10000 cycles, should your FLASH be exceptionally
> good and not generate bit errors before that. Try a different page
> offset in that case.
>
> Please note that neither of these tests will significantly 'use up' any FLASH
> endurance. Only a maximum of two erase operations will be performed.
>
> Signed-off-by: Iwo Mergler <Iwo.Mergler@netcommwireless.com.au>
> ---
> drivers/mtd/tests/Makefile | 1 +
> drivers/mtd/tests/mtd_nandbiterrs.c | 460 +++++++++++++++++++++++++++++++++++
> 2 files changed, 461 insertions(+), 0 deletions(-)
> create mode 100644 drivers/mtd/tests/mtd_nandbiterrs.c
>
> diff --git a/drivers/mtd/tests/Makefile b/drivers/mtd/tests/Makefile
> index b44dcab..bd0065c 100644
> --- a/drivers/mtd/tests/Makefile
> +++ b/drivers/mtd/tests/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_MTD_TESTS) += mtd_stresstest.o
> obj-$(CONFIG_MTD_TESTS) += mtd_subpagetest.o
> obj-$(CONFIG_MTD_TESTS) += mtd_torturetest.o
> obj-$(CONFIG_MTD_TESTS) += mtd_nandecctest.o
> +obj-$(CONFIG_MTD_TESTS) += mtd_nandbiterrs.o
> diff --git a/drivers/mtd/tests/mtd_nandbiterrs.c b/drivers/mtd/tests/mtd_nandbiterrs.c
> new file mode 100644
> index 0000000..94e908e
> --- /dev/null
> +++ b/drivers/mtd/tests/mtd_nandbiterrs.c
> @@ -0,0 +1,460 @@
> +/*
> + * (C)2012 NetCommWireless
> + * Iwo Mergler <Iwo.Mergler@netcommwireless.com.au>
> + *
> + * Test for multi-bit error recovery on a NAND page This mostly tests the
> + * ECC controller / driver.
> + *
> + * There are two test modes:
> + *
> + * 0 - artificially inserting bit errors until the ECC fails
> + * This is the default method and fairly quick. It should
> + * be independent of the quality of the FLASH.
> + *
> + * 1 - re-writing the same pattern repeatedly until the ECC fails.
> + * This method relies on the physics of NAND FLASH to eventually
> + * generate '0' bits if '1' has been written sufficient times.
> + * Depending on the NAND, the first bit errors will appear after
> + * 1000 or more writes and then will usually snowball, reaching the
> + * limits of the ECC quickly.
> + *
> + * The test stops after 10000 cycles, should your FLASH be
> + * exceptionally good and not generate bit errors before that. Try
> + * a different page in that case.
So basically you test that ECC works, and you are trying to be
independent on the NAND HW and the ECC type. Right?
How about mtd_nandecc test? How is it different? Do we need 2 tests?
Why?
Akinobu - you recently sent a large patch-set for mtd_nandecctest, could
you please also comment on the above questions?
Basically, I would like to understand why we need 2 tests, and if we
really need 2, have the differences be documented, at least in the
commentaries.
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-09-03 15:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-29 7:26 [PATCH] Test for multi-bit error correction Iwo Mergler
2012-08-30 7:00 ` Artem Bityutskiy
2012-08-30 8:05 ` Iwo Mergler
2012-08-30 8:24 ` Artem Bityutskiy
2012-08-30 22:49 ` Iwo Mergler
2012-08-30 22:59 ` Iwo Mergler
2012-09-03 15:25 ` Artem Bityutskiy [this message]
2012-09-04 8:16 ` Akinobu Mita
2012-09-05 8:28 ` Iwo Mergler
2012-09-05 18:19 ` Brian Norris
2012-09-06 3:37 ` Iwo Mergler
2012-09-17 18:42 ` Brian Norris
2012-09-23 13:41 ` Artem Bityutskiy
2012-09-23 13:42 ` 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=1346685918.3061.66.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=Iwo.Mergler@netcommwireless.com \
--cc=akinobu.mita@gmail.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