Spurious ECC errors with mtd_subpagetest (OMAP3, NAND)

Spurious ECC errors with mtd_subpagetest (OMAP3, NAND)

[Orjan Friberg]

Hi,

When running the mtd_subpagetest I'm seeing more or less spurious ECC 
corrections.  I.e., one round may show 4 corrections and the next will 
show 7, only some of which are the same as the previous 4.

Are the ECC errors expected to be that volatile and frequent?


I've seen various discussions regarding the OMAP sub page support, as 
well as problems with the GPMC prefetch engine.  Disabling both made no 
difference regarding this.  I've also tried two different sets of NAND 
timings (relaxed and optimized), with no difference.

I'm using a Micron NAND that requires 4-bit ECC correction but I'm 
running with only 1-bit (software) ECC.  This is on an old kernel, 2.6.32.

Thanks,
Orjan

-- 
Orjan Friberg
FlatFrog Laboratories AB

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Spurious ECC errors with mtd_subpagetest (OMAP3, NAND)

[Orjan Friberg]

On 03/02/2012 05:17 PM, Orjan Friberg wrote:
> Hi,
>
> When running the mtd_subpagetest I'm seeing more or less spurious ECC
> corrections.  I.e., one round may show 4 corrections and the next will
> show 7, only some of which are the same as the previous 4.

FWIW

* I'm seeing the same behaviour (i.e. transient ECC errors) when doing 
nanddump on a partition.
* mtd_oobtest fails on "verify failed at <varying address>", and "read 
past end of device".


-- 
Orjan Friberg
FlatFrog Laboratories AB

Re: Spurious ECC errors with mtd_subpagetest (OMAP3, NAND)

[Grazvydas Ignotas]

Hello,

On Fri, Mar 2, 2012 at 6:17 PM, Orjan Friberg <of@flatfrog.com> wrote:
> When running the mtd_subpagetest I'm seeing more or less spurious ECC
> corrections.  I.e., one round may show 4 corrections and the next will show
> 7, only some of which are the same as the previous 4.
>
> Are the ECC errors expected to be that volatile and frequent?
>
>
> I've seen various discussions regarding the OMAP sub page support, as well
> as problems with the GPMC prefetch engine.  Disabling both made no
> difference regarding this.  I've also tried two different sets of NAND
> timings (relaxed and optimized), with no difference.
>
> I'm using a Micron NAND that requires 4-bit ECC correction but I'm running
> with only 1-bit (software) ECC.  This is on an old kernel, 2.6.32.

IIRC NAND in mainline was broken for very long time on OMAP3, I think
it was only fixed in 2.6.39.1.

-- 
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Spurious ECC errors with mtd_subpagetest (OMAP3, NAND)

[Orjan Friberg]

On 03/02/2012 06:17 PM, Grazvydas Ignotas wrote:
> IIRC NAND in mainline was broken for very long time on OMAP3, I think
> it was only fixed in 2.6.39.1.

That seems to be the case; the 2.6.39.1 diff contains the OMAP NAND sub 
page write fix (applied locally).


Anyone else who can testify on the "volatile-ness" of NAND ECC errors?

I.e., are they expected to be more persistent?


Thanks,
Orjan

-- 
Orjan Friberg
FlatFrog Laboratories AB

Re: Spurious ECC errors with mtd_subpagetest (OMAP3, NAND)

[Matthieu CASTET]

Hi,

Orjan Friberg a écrit :
> On 03/02/2012 06:17 PM, Grazvydas Ignotas wrote:
>> IIRC NAND in mainline was broken for very long time on OMAP3, I think
>> it was only fixed in 2.6.39.1.
> 
> That seems to be the case; the 2.6.39.1 diff contains the OMAP NAND sub 
> page write fix (applied locally).
> 
Note that the omap driver is still broken :
http://article.gmane.org/gmane.linux.drivers.mtd/36079/match=

We detected this when stressing a board.

Because all of these bugs in omap driver, I wonder how many people really use
the mainline version.


Also if you use a nand that need 4-bit ECC, you need a better ecc than hamming.
You can use the bch code (
http://article.gmane.org/gmane.linux.drivers.mtd/37864/match=omap )

Matthieu

PS : why omap driver use in omap_dev_ready GPMC*IRQ_STATUS instead of GPMC_STATUS.

PS2 : ecc hamming look strange. Weird isEccFF code. Doesn't seem to handle bit
flip in ecc.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Spurious ECC errors with mtd_subpagetest (OMAP3, NAND)

[Orjan Friberg]

On 03/05/2012 09:56 AM, Matthieu CASTET wrote:
> Note that the omap driver is still broken :
> http://article.gmane.org/gmane.linux.drivers.mtd/36079/match=
>
> We detected this when stressing a board.
>
> Because all of these bugs in omap driver, I wonder how many people really use
> the mainline version.

Do you know any repo where this is working correctly (linux-omap, or one 
of the vendor trees etc)?

> Also if you use a nand that need 4-bit ECC, you need a better ecc than hamming.
> You can use the bch code (
> http://article.gmane.org/gmane.linux.drivers.mtd/37864/match=omap )

Yes, I've been looking at the BCH 4-bit code (both generic 
implementations and the OMAP GPMC-enabled one) in u-boot and linux.


-- 
Orjan Friberg
FlatFrog Laboratories AB