public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Vipin Kumar <vipin.kumar@st.com>
To: Ivan Djelic <ivan.djelic@parrot.com>
Cc: "Artem.Bityutskiy@nokia.com" <Artem.Bityutskiy@nokia.com>,
	Viresh KUMAR <viresh.kumar@st.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"David.Woodhouse@intel.com" <David.Woodhouse@intel.com>
Subject: Re: [PATCH] Newly erased page read workaround
Date: Thu, 24 Feb 2011 15:50:59 +0530	[thread overview]
Message-ID: <4D66310B.1050706@st.com> (raw)
In-Reply-To: <20110224093800.GA7880@parrot.com>

On 2/24/2011 3:08 PM, Ivan Djelic wrote:
> On Thu, Feb 24, 2011 at 06:10:16AM +0000, Viresh Kumar wrote:
>> From: Vipin Kumar <vipin.kumar@st.com>
>>
>> A newly erased page contains ff in data as well as spare area. While reading an
>> erased page, the read out ecc from spare area does not match the ecc generated
>> by fsmc ecc hardware accelarator. This is because ecc of data ff ff is not ff
>> ff. This leads to errors when jffs2 fs erases and reads back the pages to
>> ensure consistency.
>>
>> This patch adds a software workaround to ensure that the ecc check is not
>> performed for erased pages. An erased page is checked by checking data as ff ff.
> 
> Hello Vipin,
> 

Hello Ivan,

> Just a suggestion: maybe you could mention in your comments the fact that you
> cannot workaround the problem using a mask to get a valid ECC on erased pages,
> because your controller does not allow it ?
> 
> If you plan to use your workaround on recent NAND devices with UBIFS, you may
> still experience problems because of uncorrected bitflips on erased pages, and
> get errors such as:
> 

Let me explain the problem again.

The problem is that the BCH algorithm (used by this controller to generate ecc 
and correct bitflips) generates an ecc which is not 0xffff for an erased 512 
bytes.

Since erasing a page results in all data including the spare area of the page 
resetting to 0xffff, and the ecc written in the spare area is incorrect.
This ecc is not useful to correct bitflips

One way to solve this problem is to write the correct ecc in the erased pages 
spare area. The other is to ensure that the page is erased and not run the 
correction algorithm. We are using the second option but there would not be 
any unwanted bitflips in any of the cases.

Let me know if this answers your questions

> UBIFS error (pid 576): ubifs_scan: corrupt empty space at LEB 509:126586
> UBIFS error (pid 576): ubifs_scanned_corruption: corruption at LEB 509:126586
> UBIFS error (pid 576): ubifs_scan: LEB 509 scanning failed
> UBIFS warning (pid 576): ubifs_ro_mode: switched to read-only mode, error -117
> 
> Regards,
> 
> Ivan
> .
> 

Regards
Vipin

  reply	other threads:[~2011-02-24 10:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-24  6:10 [PATCH] Newly erased page read workaround Viresh Kumar
2011-02-24  9:38 ` Ivan Djelic
2011-02-24 10:20   ` Vipin Kumar [this message]
2011-02-24 11:10     ` Ivan Djelic
2011-02-24 11:36       ` Vipin Kumar
2011-03-22  4:36 ` viresh kumar
2011-03-31 13:51 ` Artem Bityutskiy
2011-04-01  6:28   ` Vipin Kumar
2011-04-01  6:51     ` Artem Bityutskiy
2011-04-01  8:33       ` Vipin Kumar
2011-04-01  8:39         ` Artem Bityutskiy
2011-04-01  9:06           ` Vipin Kumar
2011-04-01  9:42             ` Artem Bityutskiy
2011-04-01 12:14             ` Ivan Djelic
2011-04-01 13:04               ` Artem Bityutskiy
2011-04-01 14:04                 ` Ivan Djelic
2011-04-01 14:16                   ` Artem Bityutskiy
2011-04-01 14:49                     ` Ivan Djelic
2011-04-01 14:58                       ` Ricard Wanderlof
2011-04-01 15:46                         ` Ivan Djelic
2011-04-01 16:09                     ` Ivan Djelic
2011-04-01 16:16                       ` 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=4D66310B.1050706@st.com \
    --to=vipin.kumar@st.com \
    --cc=Artem.Bityutskiy@nokia.com \
    --cc=David.Woodhouse@intel.com \
    --cc=ivan.djelic@parrot.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=viresh.kumar@st.com \
    /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