public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: hujianyang <hujianyang@huawei.com>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH] UBI: improve messages in ubi_eba_read_leb()
Date: Fri, 15 May 2015 16:23:54 +0800	[thread overview]
Message-ID: <5555AD1A.40909@huawei.com> (raw)
In-Reply-To: <CAFLxGvwJ9LhbPhcyEyq91+_jLDcd1XtbmcCHTGCSSk+J4ZCTWw@mail.gmail.com>

On 2015/2/10 17:30, Richard Weinberger wrote:
> On Tue, Feb 10, 2015 at 9:05 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
>> On Tue, 2015-02-10 at 11:40 +0800, hujianyang wrote:
>>> If an error occur while reading from PEBs, for example, an ECC error,
>>> ubi_io_read() will print some error messages. But it's not enough for
>>> debugging. These messages don't show the mapping info for a read from
>>> UBIFS layer.
>>>
>>> Although UBIFS will soon print its error messages after catching the
>>> return value from UBI layer,  multi-path reading will confuse the
>>> relationship between LEBs and PEBs showed by these messages, like:
>>>
>>> [   38.442770] UBI error: ubi_io_read: error -74 (ECC error) while reading 26624 bytes from PEB 54:104448, read 26624 bytes
>>> [   38.852461] UBI error: ubi_io_read: error -74 (ECC error) while reading 77824 bytes from PEB 346:53248, read 77824 bytes
>>> [   38.864142] UBIFS error (pid 1444): ubifs_recover_leb: corruption -3
>>> [   38.870487] UBIFS error (pid 1444): ubifs_scanned_corruption: corruption at LEB 928:55280
>>> [   38.878625] UBIFS error (pid 1444): ubifs_scanned_corruption: first 8192 bytes from LEB 928:55280
>>> [   38.892117] UBIFS error (pid 1444): ubifs_recover_leb: LEB 928 scanning failed
>>> mount: mounting ubi1:bak on /mountpoint: failed: Structure needs cleaning
>>>
>>> This patch improve the output of ubi_eba_read_leb() by printing the
>>> mapping of LEB and PEB if an ECC error occur. And also, print PEB
>>> and LEB number if a CRC error occur.
>>>
>>> Signed-off-by: hujianyang <hujianyang@huawei.com>
>>
>> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> 
> As the merge window is already open I'd wait until the next merge
> window with that patch.
> 

Ping?

      reply	other threads:[~2015-05-15  8:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-10  3:40 [PATCH] UBI: improve messages in ubi_eba_read_leb() hujianyang
2015-02-10  8:05 ` Artem Bityutskiy
2015-02-10  9:30   ` Richard Weinberger
2015-05-15  8:23     ` hujianyang [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=5555AD1A.40909@huawei.com \
    --to=hujianyang@huawei.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard.weinberger@gmail.com \
    --cc=richard@nod.at \
    /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