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
>
next prev parent 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