All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Mark <xiaoming1981.zhang@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBIFS mount failure upon power off
Date: Sun, 22 Apr 2012 17:24:36 +0300	[thread overview]
Message-ID: <1335104676.7078.5.camel@golum> (raw)
In-Reply-To: <4F940D08.3080101@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2332 bytes --]

On Sun, 2012-04-22 at 21:52 +0800, Mark wrote:
> On 04/22/2012 09:15 PM, Artem Bityutskiy wrote:
> > Hi,
> >
> > On Wed, 2012-04-11 at 20:17 +0800, Mark wrote:
> >>  brcmnand_read_page: 3: brcmnand_posted_read_cache failed at
> >>  offset=3c81c00, ret=-77
> >>  UBI error: ubi_io_read: error -77 while reading 126976 bytes from PEB
> >>  21:4096, read 2048 bytes
> >>  UBIFS error (pid 484): ubifs_start_scan: cannot read 126976 bytes from
> >>  LEB 18:0, error -5
> >>  mount: mounting ubi13_0 on /usr/local/appdata failed: Input/output
> >>  error
> >>
> > Please fix your NAND driver and why it returns strange error code
> > -EBADFD (-77). Uncorrectable ECC errors should be reported as -EBADMSG
> > instead. Bit-flips as -EUCLEAN.
> >
> 
> Thank you very much, I still have some questions:
> 
> 1. I'm using mips platform so I think "-77" is "-EBADMSG":
>        ./arch/mips/include/asm/errno.h:51:#define      EBADMSG 
> 77      /* Not a data message */

Oh, ok, sorry.

> 
> 2. I found these comments in ubi_io_read():
> 	        /* 
>  
> 
>                   * The driver should never return -EBADMSG if it failed 
> to read 
> 
>                   * all the requested data. But some buggy drivers might 
> do 
> 
>                   * this, so we change it to -EIO. 
>  
> 
>                   */
> 
>     but seems my nand driver do_read_ops() function returns immediately
>     on an ecc error. Why the driver must continue reading the left data?

Yes, I ask the driver to read 5 NAND pages, then it should read all 5,
even if the second one has unrecoverable ECC error. But if any page had
ECC errors, it should return -EBADMSG.

> 
> 3. I fixed this problem, in most situations the ubifs can recover 
> successfully,
>     but I still get this error (though difficult to reproduce):
> 
>         UBI error: ubi_io_read: error -77 while reading 126976 bytes 
> from PEB 2:4096, read 126976 bytes
>         UBIFS error (pid 481): insert_node: duplicate sqnum in replay
>         mount: mounting ubi13_0 on /usr/local/hmt/appdata failed: 
> Invalid argument
> 
>     What could be the reason?

Difficult to say, enable UBI debugging - it will print more information
(not all the debugging messages, just debugging).

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      parent reply	other threads:[~2012-04-22 14:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-11 12:17 UBIFS mount failure upon power off Mark
2012-04-22 12:44 ` Artem Bityutskiy
2012-04-22 13:15 ` Artem Bityutskiy
2012-04-22 13:52   ` Mark
2012-04-22 14:23     ` Artem Bityutskiy
2012-04-22 14:31       ` Artem Bityutskiy
2012-04-22 15:01         ` Mark
2012-04-22 14:24     ` Artem Bityutskiy [this message]

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=1335104676.7078.5.camel@golum \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=xiaoming1981.zhang@gmail.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 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.