public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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.

  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