Problems in Out of tree TI SDK omap2-nand driver (Re: [PATCH 3/3] nandtest: Introduce multiple reads & check iterations)

Gupta, Pekon pekon at
Mon May 5 11:12:55 PDT 2014

>From: Ezequiel Garcia [mailto:ezequiel at]
>I've changed the subject of this mail, since it seems we've moved from the
>On 05 May 10:58 AM, Gupta, Pekon wrote:
>> However, I know of some issues in OMAP NAND driver bundled with
>> 3.2 kernel, which might be helpful in nailing down your specific issue.
>FWIW, I'm not using such driver anymore. Right after spotting this, we've
>ran the *same* test on the mainline driver, which passed. This was the kick
>we needed to start using mainline (we also need mainline for other reasons).
>> (1) 3.2 kernel does not have concept of bitflip_threshold, so by default
>> scrubbing and peb_torture happens even for single bit-flips. So please
>> pull-in following patch series.
>> [PATCH v2 0/7] mtd: Change meaning of -EUCLEAN return code on reads
>Isn't this series related to the higher-level treatment of bitflips?
>In that case, it's not related to the issue I got. Keep in mind that
>this simple test failed in our v3.2 stress (using this nandtest patch):
>  * erase
>  * write
>  * read
>  * read
>  * ...
>  * read (20 times)
>> (2) OMAP NAND in 3.2 kernel does not factor bit-flips in empty pages
>> Hence if empty pages with bit-flips are encountered, then it treats them
>> like programmed pages and expects a ECC correction on them. But as
>> empty pages do not have ECC stored in OOB, the driver bails out giving
>> 'uncorrectable ecc' read errors.
>Since the test doesn't involve empty pages, I'd say this is not relevant.
>If you're still interested in debugging the problematic TI SDK omap2-nand
>driver, I suggest that you try using this nandtest patch and see how it
>Despite you saying drivers can fail the test, I think it's still a nice test.
>Keep in mind the nandtest tool reports the number of corrected ECC errors
>after reads, so if that number is adding-up and increasing you can even
>use this patch to see this evolution.
>All in all, I think it's still a nice improvement on stock nandtest.

I was just presenting my view that
With multiple re-reads nand-test may fail randomly on some devices
due of accumulation of bitflips because of read-disturb errors.
However, this may not be the case on actual file-system like UBIFS
where upper layer performs scrubbing to avoid bit-flip accumulation.

Otherwise I have no issue with the patch. So if Artem | Brian feel okay,
they can anyways pick the patch.

with regards, pekon

More information about the linux-mtd mailing list