public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Yan Kong <ykong@sierrawireless.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: UBI errors when "ls -l"
Date: Wed, 10 Dec 2014 14:55:15 +0100	[thread overview]
Message-ID: <548850C3.8000204@nod.at> (raw)
In-Reply-To: <740E8392C144C64FA5300E5E696A179BB97FEBB176@carmd-exchmb01.sierrawireless.local>

Hi!

Am 10.12.2014 um 14:51 schrieb Yan Kong:
> Hi Richard,
> 
> Could you please give me some manuals for UBI and MTD test?

Please see the MTD website:
http://www.linux-mtd.infradead.org/doc/general.html

UBI tests are part of the mtd-utils source package.

Thanks,
//richard

> Thank you very much!
> 
> -----Original Message-----
> From: Richard Weinberger [mailto:richard@nod.at] 
> Sent: 2014年12月10日 21:24
> To: Yan Kong
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: UBI errors when "ls -l"
> 
> Am 10.12.2014 um 14:10 schrieb Yan Kong:
>> Hi, Richard,
>>
>> Your question,
>> Is this a vanilla kernel or does it carry tons of vendor patches?
>> --- I use the Kernel based on Yocto 1.6, but includes lots Qualcomm patches.
>>
>>> ubiattach /dev/ubi_ctrl -m 3 -O 4096
>>
>> Why do you need -O?
>> --- I also tried without -O. But the result is the same.
>>
>> Please use ubi tools to flash the image.
>> (dd should work, but just in case...)
>> --- I ever tried " ubiformat /dev/mtd7 -f ubi.img -s 4096", the same error :(.
>>
>> What is line 213 in your drivers/mts/ubi/io.c?
>> --- I marked line 213 as follow, thank you.
>>
>> int ubi_io_read(const struct ubi_device *ubi, void *buf, int pnum, int offset,
>> 		int len)
>> {
>> 	int err, retries = 0;
>> 	size_t read;
>> 	loff_t addr;
>>
>> 	dbg_io("read %d bytes from PEB %d:%d", len, pnum, offset);
>>
>> 	ubi_assert(pnum >= 0 && pnum < ubi->peb_count);
>> 	ubi_assert(offset >= 0 && offset + len <= ubi->peb_size);
>> 	ubi_assert(len > 0);
>>
>> 	err = paranoid_check_not_bad(ubi, pnum);
>> 	if (err)
>> 		return err;
>>
>> 	/*
>> 	 * Deliberately corrupt the buffer to improve robustness. Indeed, if we
>> 	 * do not do this, the following may happen:
>> 	 * 1. The buffer contains data from previous operation, e.g., read from
>> 	 *    another PEB previously. The data looks like expected, e.g., if we
>> 	 *    just do not read anything and return - the caller would not
>> 	 *    notice this. E.g., if we are reading a VID header, the buffer may
>> 	 *    contain a valid VID header from another PEB.
>> 	 * 2. The driver is buggy and returns us success or -EBADMSG or
>> 	 *    -EUCLEAN, but it does not actually put any data to the buffer.
>> 	 *
>> 	 * This may confuse UBI or upper layers - they may think the buffer
>> 	 * contains valid data while in fact it is just old data. This is
>> 	 * especially possible because UBI (and UBIFS) relies on CRC, and
>> 	 * treats data as correct even in case of ECC errors if the CRC is
>> 	 * correct.
>> 	 *
>> 	 * Try to prevent this situation by changing the first byte of the
>> 	 * buffer.
>> 	 */
>> 	*((uint8_t *)buf) ^= 0xFF;
>>
>> 	addr = (loff_t)pnum * ubi->peb_size + offset;
>> retry:
>> 	err = mtd_read(ubi->mtd, addr, len, &read, buf);
>> 	if (err) {
>> 		const char *errstr = mtd_is_eccerr(err) ? " (ECC error)" : "";
>>
>> 		if (mtd_is_bitflip(err)) {
>> 			/*
>> 			 * -EUCLEAN is reported if there was a bit-flip which
>> 			 * was corrected, so this is harmless.
>> 			 *
>> 			 * We do not report about it here unless debugging is
>> 			 * enabled. A corresponding message will be printed
>> 			 * later, when it is has been scrubbed.
>> 			 */
>> 			dbg_msg("fixable bit-flip detected at PEB %d", pnum);
>> 			ubi_assert(len == read);
>> 			return UBI_IO_BITFLIPS;
>> 		}
>>
>> 		if (retries++ < UBI_IO_RETRIES) {
>> 			dbg_io("error %d%s while reading %d bytes from PEB "
>> 			       "%d:%d, read only %zd bytes, retry",
>> 			       err, errstr, len, pnum, offset, read);
>> 			yield();
>> 			goto retry;
>> 		}
>>
>> 		ubi_err("error %d%s while reading %d bytes from PEB %d:%d, "
>> 			"read %zd bytes", err, errstr, len, pnum, offset, read);
>> 		ubi_dbg_dump_stack();
>>
>> 		/*
>> 		 * 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.
>> 		 */
>> 		if (read != len && mtd_is_eccerr(err)) {
>> 			ubi_assert(0);
>> 			err = -EIO;
>> 		}
>> 	} else {
>> 		ubi_assert(len == read);      <--------------------------------- line 213
> 
> Looks much like a broken MTD driver.
> mtd_read() returned less than requested bytes.
> Please make sure that both UBI and MTD tests pass.
> 
> Thanks,
> //richard
> 

  reply	other threads:[~2014-12-10 13:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10  9:34 UBI errors when "ls -l" Yan
2014-12-10 10:40 ` Richard Weinberger
2014-12-10 13:10   ` Yan Kong
2014-12-10 13:24     ` Richard Weinberger
2014-12-10 13:51       ` Yan Kong
2014-12-10 13:55         ` Richard Weinberger [this message]
2014-12-12  8:03           ` Yan Kong
2014-12-12  8:21             ` Richard Weinberger
2014-12-15  3:30               ` Yan Kong
2014-12-15  8:36                 ` Richard Weinberger
2014-12-15  8:53                   ` Yan Kong

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=548850C3.8000204@nod.at \
    --to=richard@nod.at \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ykong@sierrawireless.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox