UBI errors when "ls -l"

[Yan Kong]

Hi Richard,

I have ran "mtd_oobtest" for mtd3, failed.....
(I erase mtd3 before I run the test, by "flash_erase /dev/mtd3 0 0 -N").
Do you know is it the mtd driver issue or hardware issue?
It seems other mtd tests can be passed.
Thank you!

[  329.171158] 
[  329.171799] =================================================
[  329.184220] mtd_oobtest: MTD device: 3
[  329.187120] mtd_oobtest: MTD device size 41680896, eraseblock size 262144, page size 4096, count of eraseblocks 159, pages per eraseblock 64, OOB size 224
[  329.200885] mtd_oobtest: scanning for bad eraseblocks
[  329.222462] mtd_oobtest: scanned 159 eraseblocks, 0 are bad
[  329.227163] mtd_oobtest: test 1 of 5
[  329.230581] mtd_oobtest: erasing whole device
[  329.508927] mtd_oobtest: erased 159 eraseblocks
[  329.512437] mtd_oobtest: writing OOBs of whole device
[  329.519761] msm_nand_write_oob: unsupported ops->datbuf == NULL
[  329.526964] mtd_oobtest: error: writeoob failed at 0x0
[  329.531084] mtd_oobtest: error: use_len 32, use_offset 0
[  329.536456] mtd_oobtest: error -22 occurred
[  329.540546] =================================================
insmod: can't insert 'mtd_oobtest.ko': invalid parameter



-----Original Message-----
From: Richard Weinberger [mailto:richard at nod.at] 
Sent: 2014年12月10日 21:55
To: Yan Kong
Cc: linux-mtd at lists.infradead.org
Subject: Re: UBI errors when "ls -l"

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 at nod.at] 
> Sent: 2014年12月10日 21:24
> To: Yan Kong
> Cc: linux-mtd at 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
>