public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Mike Dunn <mikedunn@newsguy.com>
To: linux-mtd@lists.infradead.org
Subject: Re: Problems with mtd_oobtest
Date: Fri, 02 Mar 2012 17:19:55 -0800	[thread overview]
Message-ID: <4F5171BB.2010708@newsguy.com> (raw)
In-Reply-To: <CAHMF36F1Vd6=3YuQhKE_qEXm3hjGbbm=mmuMbQdt1i6Z=66zNQ@mail.gmail.com>

On 03/01/2012 04:16 AM, Matej Kupljen wrote:

>>> I can run mtd_speedtest, mtd_stresstest, mtd_readtest, mtd_pagetest without the
>>> problems, but when I start the mtd_oobtest it fails, basically on every page!
>>
>>
>> Your flash device probably does not support writing oob-only.  This is true of
>> some NAND devices.  I wouldn't worry about this test.  This failure is probably
>> unrelated to your ubifs problems.
> 
> Well, I haven't found that anywhere, so I was wondering in the dark :)
> I was looking at the code, but could find anything.


Take a look at how your driver handles writing oob-only.  Ideally it would
return -EOPNOTSUPP, but at least two drivers I know of silently save the data
and only do the oob write if the next operation is to write the page data itself
to the same page.  This is a hack to make utilities like nandwrite work.  This
utility assumes that oob can be written separately, and writes oob first, then
page data,  This is not possible on some NANDs where oob must be written at the
same time as the page data.  The disadvantage of the hack is that if the oob
write is not immediately followed by the page data write, the oob write silently
fails.  mtd_oobtest does not write the page data, only oob, and the fact that it
fails on every page suggests a situation like this.  I doubt it's relevant to
your ubifs troubles.

> 
>>> I can use JFFS2 on this device, and for some time even UBIFS, but then
>>> it just fails.
>>
>>
>> What is the nature of the ubifs failure?  The kernel log should tell you.  It
>> may be the same problem I experience, where over time too many erase bocks are
>> marked as bad.  This is due to the unforgiving nature of ubi wrt corrected
>> bitflips, and tends to be a problem on NAND flash devices with high bit errors,
>> for which the device compensates with strong ecc.  I'm working on some patches
>> that should fix this.
> 
> I re-flashed the UBFS image to my FLASH and have booted the device.
> It boots without the problem and here is the log (Please note, that is
> uses sub pages):


I'm not a ubi/ubifs expert, but if you're not sure how ubifs is failing, I
suggest running ubiformat on a blank device and then run some of the ubi test
utilities in mtd-utils, starting with io_basic.  If the problem is like the one
I'm having, the test will eventually fail (leave it running for a while) and the
error messages from ubi in the kernel log will likely be revealing.

Hope this helps.

Mike

  reply	other threads:[~2012-03-03  1:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-01 12:16 Problems with mtd_oobtest Matej Kupljen
2012-03-03  1:19 ` Mike Dunn [this message]
2012-03-09 12:13 ` Artem Bityutskiy
  -- strict thread matches above, loose matches on Subject: below --
2012-02-28  7:02 Matej Kupljen
2012-02-29 16:06 ` Mike Dunn
2012-03-09 10:35 ` 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=4F5171BB.2010708@newsguy.com \
    --to=mikedunn@newsguy.com \
    --cc=linux-mtd@lists.infradead.org \
    /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