From: Mike Dunn <mikedunn@newsguy.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Artem Bityutskiy <dedekind1@gmail.com>,
Richard Weinberger <richard@nod.at>,
Kevin Cernekee <cernekee@gmail.com>,
Jim Quinlan <jim2101024@gmail.com>,
linux-mtd@lists.infradead.org, Al Viro <viro@zeniv.linux.org.uk>,
Joel Reardon <reardonj@inf.ethz.ch>,
ivan.djelic@parrot.com, David Woodhouse <dwmw2@infradead.org>,
Shmulik Ladkani <shmulik.ladkani@gmail.com>
Subject: Re: MLC NAND: all 0xff after erase?
Date: Wed, 11 Jul 2012 09:46:52 -0700 [thread overview]
Message-ID: <4FFDADFC.5020503@newsguy.com> (raw)
In-Reply-To: <CAN8TOE9RyUuRtEfyqBfxt0W3Cfg2_SD6Hp4rMS0S+MgKsPY9UQ@mail.gmail.com>
> * My NAND controller's HW ECC flags these erased-page bitflips as
> uncorrectable errors, as there was no ECC written to the page and the
> read data does not match the 0xff special "erased" case. I assume most
Ditto for the newer diskonchips...
> other ECC mechanisms would treat this similarly [2]. In such cases, I
> suspect that the best the driver can do is to return the raw data
> (0xff with flips) and an ECC error message.
>
> * UBI and other FS layers need to distinguish between: (a) 0xff
> cleanly-erased, (b) 0xff with bitflips, and (c) true ECC errors. In
> the end, we may treat (a) and (b) the same (as erased pages), but the
> problem is distinguishing between (b) and (c).
To distinguish between (b) and (c), the docg4 driver dedicates an unused oob
byte as a "page written" flag. This byte is cleared whenever the page is
written. When uncorrectible bitflip errors occur, if more than half of the bits
in this flag are set, the page is assumed to be blank, but with bitflips. In
this case the driver quietly ignores the ecc error, but returns the blank page
data with the bitflips. Not a complete solution, and also specific to one
particular driver, but food for thought. This scheme was actually suggested by
Ivan Djelic.
Mike
next prev parent reply other threads:[~2012-07-11 16:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-11 0:36 MLC NAND: all 0xff after erase? Brian Norris
2012-07-11 6:41 ` Richard Genoud
2012-07-13 21:22 ` Brian Norris
2012-07-11 16:46 ` Mike Dunn [this message]
2012-07-11 17:43 ` Ivan Djelic
2012-08-07 10:11 ` Calvin Johnson
[not found] ` <CAEhpT-UMk0hiDaKAwn8GtS0B3HHRudbSUSHpZ68-i+LmMNH-=A@mail.gmail.com>
2012-08-07 20:00 ` Ivan Djelic
2012-08-09 3:50 ` Calvin Johnson
2012-08-17 9:51 ` Artem Bityutskiy
2012-08-17 13:54 ` Matthieu CASTET
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=4FFDADFC.5020503@newsguy.com \
--to=mikedunn@newsguy.com \
--cc=cernekee@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ivan.djelic@parrot.com \
--cc=jim2101024@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=reardonj@inf.ethz.ch \
--cc=richard@nod.at \
--cc=shmulik.ladkani@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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.