From: David Jander <david.jander@protonic.nl>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Ted Juan <ted.juan@gmail.com>,
"sjhill@realitydiluted.com" <sjhill@realitydiluted.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND
Date: Wed, 25 Jun 2014 13:31:29 +0200 [thread overview]
Message-ID: <20140625133129.060cd535@archvile> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EAF7560@DBDE04.ent.ti.com>
Dear Pekon,
On Wed, 25 Jun 2014 10:04:11 +0000
"Gupta, Pekon" <pekon@ti.com> wrote:
> Hi Ted,
>
> >From: Ted Juan [mailto:ted.juan@gmail.com]
> >Dear Pekon,
> >
> >I backup the raw data to data2[] before doing elm_decode_bch_error_page();
> >Dump code is as below. The raw data is the same with the correction
> >data that all more than 8 bit-flips.
> >
> (a) In that case you should contact the Flash vendor here.
> Fresh NAND device from factory should not violate the spec.
> I don't suspect a driver issue here, because the raw data read itself
> has random bit-flips.
Sorry to interrupt, but this does sound serious. Are you absolutely sure your
hardware is OK? Is the power-supply clean and well enough decoupled? Timings
within specs?
If electrical specifications are not met, this could explain the bit-flips. It
is possible that Samsung is at fault here (they screwed up the specs for this
version anyway), but double checking the hardware looks like a good idea
here...
> (b) Also, it may be the case that there few particular blocks which has gone
> bad and those are is showing again and again at each boot. However, If it
> was such a case that only some handful blocks on NAND device have gone
> bad, then UBI torture test [1] should have detected them and marked them
> bad. And those should not re-appear in next time.
> - You can check (b) by scrubbing all bad-blocks from u-boot
> #u-boot> nand scrub.chip all
> #u-boot> nand bad (should report 0 bad blocks)
> - Then, re-boot and let UBI detect bad-blocks on its own using torture-test
> - And then again reset the system 2nd time and check newly detected
> bad-blocks #u-boot> nand bad (should report [n] bad blocks)
>
> (c) You can also check, if you are seeing bit-flips only during
> erased-pages ? You can identify this by adding prints in u-boot.
> There is slight difference in u-boot and kernel omap-gpmc NAND drivers,
> - u-boot: simply ignores erased-pages and does not check for bit-flips in
> them.
> - kernel: counts number of bit-flips in erased-pages also.
>
>
> >The full data log is put as below but include some useless dump data.
> >https://drive.google.com/file/d/0BwVGpNFs7l22RmZXTHhJWXFYYWs/edit?usp=sharing
> >
> There will be no correction done if 'un-correctable error' flag is raised by
> ELM. Therefore pre-correction and post-correction data matches in below dump.
> Bit-flip correction will _only_ happen if the number of bit-flips are within
> correctable range (that is <=8 for BCH8 ECC scheme).
>
>
> [1] $kernel/drivers/mtd/ubi/io.c @@ torture_peb()
Best regards,
--
David Jander
Protonic Holland.
next prev parent reply other threads:[~2014-06-25 11:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-20 10:12 [FRC] [PATCH] MTD: nand_base.c: Enable support for Samsung E-die SLC NAND David Jander
2014-06-22 12:06 ` Ted Juan
2014-06-23 4:05 ` Gupta, Pekon
2014-06-23 8:15 ` Ted Juan
2014-06-25 6:17 ` Ted Juan
2014-06-25 10:04 ` Gupta, Pekon
2014-06-25 11:31 ` David Jander [this message]
2014-06-25 11:55 ` Gupta, Pekon
2014-06-25 12:11 ` David Jander
2014-06-30 11:06 ` Gupta, Pekon
2014-06-26 4:02 ` Ted Juan
2014-06-27 9:13 ` Ted Juan
2014-06-27 10:03 ` Gupta, Pekon
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=20140625133129.060cd535@archvile \
--to=david.jander@protonic.nl \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=pekon@ti.com \
--cc=sjhill@realitydiluted.com \
--cc=ted.juan@gmail.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.