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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox