UBI errors when "ls -l"

UBI errors when "ls -l"

[Yan]

Hi all,

My Kernel version is:
Linux swi-mdm9x15 3.4.91-yocto-standard #7 PREEMPT Wed Dec 10 17:39:02 HKT 2014 
armv7l GNU/Linux

I am trying to mount ubifs. It seems mount ubifs image successfully, but when 
access ubifs, it will print out lots of error msgs.
This is steps I do:
(1)make ubifs.image. I make ubifs image from *.conf (I tried use "mkfs.ubifs" 
and "ubinize" to make image directly, the same error msgs ).
IMAGE_FSTYPES += "ubi"
MKUBIFS_ARGS = "-m 4096 -e 253952 -c 2047"
UBINIZE_ARGS = "-m 4096 -p 256KiB -s 4096"

(2)mount ubifs In Linux shell.
mkdir -p /mnt/ubifs
flash_erase /dev/mtd3 0 0 -N
dd if=/mnt/flash/ubi.img of=/dev/mtd3 bs=4096
ubiattach /dev/ubi_ctrl -m 3 -O 4096
ubiblkvol -a /dev/ubi0_0
mount -t ubifs ubi0:swi-mdm9x15-rootfs /mnt/ubifs

(3)After step (2), ubifs can be mounted successfully. But when I access ubifs, 
such as when I input "ls", it will show lots of error msgs. But after printing 
out error msgs, finally it will show directory.
By the way, I tried to use nandsim to debug the ubi image in Ubuntu, it is OK.
I think there is something wrong in Kernel configuration.
Could you please help me? Thank you very much!
Error msgs and Kernel configuration attached.

error msgs:
[ 1126.270349] UBI assert failed in ubi_io_read at 213 (pid 427)
[ 1126.275690] [<c0015568>] (unwind_backtrace+0x0/0x138) from [<c06a23fc>] 
(dump_stack+0x20/0x24)
[ 1126.284205] [<c06a23fc>] (dump_stack+0x20/0x24) from [<c0412934>] 
(ubi_io_read+0x2a0/0x320)
[ 1126.292781] [<c0412934>] (ubi_io_read+0x2a0/0x320) from [<c0410978>] 
(ubi_eba_read_leb+0x2dc/0x400)
[ 1126.301815] [<c0410978>] (ubi_eba_read_leb+0x2dc/0x400) from [<c040faa8>] 
(ubi_leb_read+0x110/0x174)
[ 1126.310483] [<c040faa8>] (ubi_leb_read+0x110/0x174) from [<c025f388>] 
(ubifs_leb_read+0x38/0x98)
[ 1126.319670] [<c025f388>] (ubifs_leb_read+0x38/0x98) from [<c02611c8>] 
(ubifs_read_node+0x16c/0x2b4)
[ 1126.328521] [<c02611c8>] (ubifs_read_node+0x16c/0x2b4) from [<c027ebe8>] 
(ubifs_load_znode+0xb8/0x518)
[ 1126.337555] [<c027ebe8>] (ubifs_load_znode+0xb8/0x518) from [<c0264638>] 
(ubifs_lookup_level0+0x140/0x2dc)
[ 1126.347138] [<c0264638>] (ubifs_lookup_level0+0x140/0x2dc) from [<c0264820>] 
(ubifs_tnc_locate+0x4c/0x1a0)
[ 1126.356844] [<c0264820>] (ubifs_tnc_locate+0x4c/0x1a0) from [<c0264fd8>] 
(ubifs_tnc_lookup_nm+0x34/0x1b8)
[ 1126.366793] [<c0264fd8>] (ubifs_tnc_lookup_nm+0x34/0x1b8) from [<c0284fc8>] 
(ubifs_getxattr+0x12c/0x26c)
[ 1126.375797] [<c0284fc8>] (ubifs_getxattr+0x12c/0x26c) from [<c032edf4>] 
(smk_fetch+0x80/0xb0)
[ 1126.384312] [<c032edf4>] (smk_fetch+0x80/0xb0) from [<c032f2a8>] 
(smack_d_instantiate+0x16c/0x29c)
[ 1126.393254] [<c032f2a8>] (smack_d_instantiate+0x16c/0x29c) from [<c032b044>] 
(security_d_instantiate+0x38/0x40)
[ 1126.403326] [<c032b044>] (security_d_instantiate+0x38/0x40) from 
[<c013e144>] (d_instantiate+0x84/0x88)
[ 1126.412665] [<c013e144>] (d_instantiate+0x84/0x88) from [<c0258e68>] 
(ubifs_lookup+0x1bc/0x244)
[ 1126.421364] [<c0258e68>] (ubifs_lookup+0x1bc/0x244) from [<c0133d3c>] 
(__lookup_hash+0xc0/0xf8)
[ 1126.429818] [<c0133d3c>] (__lookup_hash+0xc0/0xf8) from [<c0133fe4>] 
(do_lookup+0x270/0x2b0)
[ 1126.438577] [<c0133fe4>] (do_lookup+0x270/0x2b0) from [<c0135df8>] 
(path_lookupat+0x10c/0x700)
[ 1126.447062] [<c0135df8>] (path_lookupat+0x10c/0x700) from [<c0136418>] 
(do_path_lookup+0x2c/0x68)
[ 1126.455882] [<c0136418>] (do_path_lookup+0x2c/0x68) from [<c0137de8>] 
(user_path_at_empty+0x68/0x98)
[ 1126.465008] [<c0137de8>] (user_path_at_empty+0x68/0x98) from [<c0137e3c>] 
(user_path_at+0x24/0x2c)
[ 1126.473950] [<c0137e3c>] (user_path_at+0x24/0x2c) from [<c012dea4>] 
(vfs_fstatat+0x40/0x78)
[ 1126.482313] [<c012dea4>] (vfs_fstatat+0x40/0x78) from [<c012df38>] 
(vfs_stat+0x2c/0x30)
[ 1126.490034] [<c012df38>] (vfs_stat+0x2c/0x30) from [<c012e160>] 
(sys_stat64+0x24/0x40)
[ 1126.498275] [<c012e160>] (sys_stat64+0x24/0x40) from [<c000e6a0>] 
(ret_fast_syscall+0x0/0x30)
[ 1126.506668] UBIFS error (pid 427): ubifs_check_node: bad magic 0xce5f59ff, 
expected 0x6101831
[ 1126.515153] UBIFS error (pid 427): ubifs_check_node: bad node at LEB 91:4032
[ 1126.522172] Not a node, first 24 bytes:

Re: UBI errors when "ls -l"

[Richard Weinberger]

On Wed, Dec 10, 2014 at 10:34 AM, Yan <ykong@sierrawireless.com> wrote:
> My Kernel version is:
> Linux swi-mdm9x15 3.4.91-yocto-standard #7 PREEMPT Wed Dec 10 17:39:02 HKT 2014
> armv7l GNU/Linux

Is this a vanilla kernel or does it carry tons of vendor patches?

> I am trying to mount ubifs. It seems mount ubifs image successfully, but when
> access ubifs, it will print out lots of error msgs.
> This is steps I do:
> (1)make ubifs.image. I make ubifs image from *.conf (I tried use "mkfs.ubifs"
> and "ubinize" to make image directly, the same error msgs ).
> IMAGE_FSTYPES += "ubi"
> MKUBIFS_ARGS = "-m 4096 -e 253952 -c 2047"
> UBINIZE_ARGS = "-m 4096 -p 256KiB -s 4096"
>
> (2)mount ubifs In Linux shell.
> mkdir -p /mnt/ubifs
> flash_erase /dev/mtd3 0 0 -N
> dd if=/mnt/flash/ubi.img of=/dev/mtd3 bs=4096

Please use ubi tools to flash the image.
(dd should work, but just in case...)

> ubiattach /dev/ubi_ctrl -m 3 -O 4096

Why do you need -O?
Looks fishy.

> ubiblkvol -a /dev/ubi0_0
> mount -t ubifs ubi0:swi-mdm9x15-rootfs /mnt/ubifs
>
> (3)After step (2), ubifs can be mounted successfully. But when I access ubifs,
> such as when I input "ls", it will show lots of error msgs. But after printing
> out error msgs, finally it will show directory.
> By the way, I tried to use nandsim to debug the ubi image in Ubuntu, it is OK.
> I think there is something wrong in Kernel configuration.
> Could you please help me? Thank you very much!
> Error msgs and Kernel configuration attached.
>
> error msgs:
> [ 1126.270349] UBI assert failed in ubi_io_read at 213 (pid 427)

What is line 213 in your drivers/mts/ubi/io.c?

-- 
Thanks,
//richard

RE: UBI errors when "ls -l"

[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

		if (ubi_dbg_is_bitflip(ubi)) {
			dbg_gen("bit-flip (emulated)");
			err = UBI_IO_BITFLIPS;
		}
	}

	return err;
}
-----Original Message-----
From: Richard Weinberger [mailto:richard.weinberger@gmail.com] 
Sent: 2014年12月10日 18:40
To: Yan Kong
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI errors when "ls -l"

On Wed, Dec 10, 2014 at 10:34 AM, Yan <ykong@sierrawireless.com> wrote:
> My Kernel version is:
> Linux swi-mdm9x15 3.4.91-yocto-standard #7 PREEMPT Wed Dec 10 17:39:02 
> HKT 2014 armv7l GNU/Linux

Is this a vanilla kernel or does it carry tons of vendor patches?

> I am trying to mount ubifs. It seems mount ubifs image successfully, 
> but when access ubifs, it will print out lots of error msgs.
> This is steps I do:
> (1)make ubifs.image. I make ubifs image from *.conf (I tried use "mkfs.ubifs"
> and "ubinize" to make image directly, the same error msgs ).
> IMAGE_FSTYPES += "ubi"
> MKUBIFS_ARGS = "-m 4096 -e 253952 -c 2047"
> UBINIZE_ARGS = "-m 4096 -p 256KiB -s 4096"
>
> (2)mount ubifs In Linux shell.
> mkdir -p /mnt/ubifs
> flash_erase /dev/mtd3 0 0 -N
> dd if=/mnt/flash/ubi.img of=/dev/mtd3 bs=4096

Please use ubi tools to flash the image.
(dd should work, but just in case...)

> ubiattach /dev/ubi_ctrl -m 3 -O 4096

Why do you need -O?
Looks fishy.

> ubiblkvol -a /dev/ubi0_0
> mount -t ubifs ubi0:swi-mdm9x15-rootfs /mnt/ubifs
>
> (3)After step (2), ubifs can be mounted successfully. But when I 
> access ubifs, such as when I input "ls", it will show lots of error 
> msgs. But after printing out error msgs, finally it will show directory.
> By the way, I tried to use nandsim to debug the ubi image in Ubuntu, it is OK.
> I think there is something wrong in Kernel configuration.
> Could you please help me? Thank you very much!
> Error msgs and Kernel configuration attached.
>
> error msgs:
> [ 1126.270349] UBI assert failed in ubi_io_read at 213 (pid 427)

What is line 213 in your drivers/mts/ubi/io.c?

--
Thanks,
//richard

Re: UBI errors when "ls -l"

[Richard Weinberger]

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

RE: UBI errors when "ls -l"

[Yan Kong]

Hi Richard,

Could you please give me some manuals for UBI and MTD test?
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

Re: UBI errors when "ls -l"

[Richard Weinberger]

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
> 

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

Re: UBI errors when "ls -l"

[Richard Weinberger]

Hi!

Am 12.12.2014 um 09:03 schrieb 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?

mtd_oobtest is failing because this test cannot work with your driver
as it does not implement all MTD functions.

Thanks,
//richard

RE: UBI errors when "ls -l"

[Yan Kong]

Hi Richard,

The FAE tell me that now mtd driver doesn't support only write OOB area, but not write data area. So mtd_oobtest.
But they are not sure if it is related to the UBI error. What do you think about it?

Another thing is that, I tried to enable nandsim in my Kernel, but saw that "Sub-page size" and "OOB size" of nandsim partition are different from local mtd partition's.
The parameter of nandsim are as follows, which is copied from boot up logs.
Command of insmod nandsim is:
modprobe nandsim first_id_byte=0x2c second_id_byte=0xac third_id_byte=0x90 fourth_id_byte=0x26
Is the parameter I used wrong?
Thank you very much!

boot up logs:
[    2.004425] msm_nand_probe: phys addr 0x1b400000
[    2.008332] msm_nand_probe: dmac 0x3
[    2.011994] msm_nand_probe: allocated dma buffer at d0074000, dma_addr 4f078000
[    2.019807] status: c00020
[    2.021852] nandid: 2690ac2c maker 2c device ac
[    2.026369] ONFI probe : Found an ONFI compliant device MT29F4G08ABBEA3W    ,
[    2.033541] Setting mtd->writebufsize to 0x1000
[    2.038028] Found supported NAND device for 8bit ECC
[    2.042972] NAND Controller ID : 0x4030
[    2.046757] NAND Device ID  : 0x2690ac2c             ------------------------------------------------------------------------> I use it as nandsim input parameters, these logs are came from boot up
[    2.050694] Buswidth : 8 Bits
[    2.053624] Density  : 512 MByte
[    2.056828] Pagesize : 4096 Bytes
[    2.060155] Erasesize: 262144 Bytes
[    2.063604] Oobsize  : 224 Bytes
[    2.066809] CFG0 Init  : 0xa95409c0
[    2.070318] CFG1 Init  : 0x08045d5c
[    2.073767] ECCBUFCFG  : 0x00000203
[    2.077765] Creating 7 MTD partitions on "msm_nand":
[    2.082313] 0x00000ea00000-0x00000eb00000 : "bootloader"
[    2.089577] 0x00000eb00000-0x00000ff40000 : "kernel"

Mtdinfo:
mtd6
Name:                           user3
Type:                           nand
Eraseblock size:                262144 bytes, 256.0 KiB
Amount of eraseblocks:          9 (2359296 bytes, 2.2 MiB)
Minimum input/output unit size: 4096 bytes
Sub-page size:                  4096 bytes                ----------------------------------------------> local mtd6, sub-page size
OOB size:                       224 bytes               -----------------------------------------------> local mtd6, OOB size
Character device major/minor:   90:12
Bad blocks are allowed:         true
Device is writable:             true

mtd7
Name:                           NAND simulator partition 0
Type:                           nand
Eraseblock size:                262144 bytes, 256.0 KiB
Amount of eraseblocks:          2048 (536870912 bytes, 512.0 MiB)
Minimum input/output unit size: 4096 bytes
Sub-page size:                  1024 bytes          ----------------------------------------------------------------> nandsim partition, Sub-page size is different from local mtd6
OOB size:                       128 bytes         ----------------------------------------------------------------> nandsim partition, OOB size is different from local mtd6
Character device major/minor:   90:14
Bad blocks are allowed:         true
Device is writable:             true


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

Hi!

Am 12.12.2014 um 09:03 schrieb 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?

mtd_oobtest is failing because this test cannot work with your driver as it does not implement all MTD functions.

Thanks,
//richard

Re: UBI errors when "ls -l"

[Richard Weinberger]

Hi!

Am 15.12.2014 um 04:30 schrieb Yan Kong:
> Hi Richard,
> 
> The FAE tell me that now mtd driver doesn't support only write OOB area, but not write data area. So mtd_oobtest.

This sentence does not parse.

> But they are not sure if it is related to the UBI error. What do you think about it?

Fact is that mtd_read() returns less bytes than requested. This must not happen and is most
likely a driver issue.
I'd start investigating here.
Almost all "UBI issues" I inspect for customers turn out to be plain mtd driver bugs.

> Another thing is that, I tried to enable nandsim in my Kernel, but saw that "Sub-page size" and "OOB size" of nandsim partition are different from local mtd partition's.
> The parameter of nandsim are as follows, which is copied from boot up logs.
> Command of insmod nandsim is:
> modprobe nandsim first_id_byte=0x2c second_id_byte=0xac third_id_byte=0x90 fourth_id_byte=0x26
> Is the parameter I used wrong?

If the ID bytes are correct everything work fine.

Thanks,
//richard

RE: UBI errors when "ls -l"

[Yan Kong]

> If the ID bytes are correct everything work fine.
Yes, the id is read from nand flash. If nandsim is correct, then something wrong exits in mtd drivers. I need to check it with FAE. Thank you.

I make a simple ubi image, only contains one folder "bin", "bin" only contains two files: only "busybox" and "vi". 


ykong@CNSHZ-ED-ARM01:~/rootfs/test_rootfs/bin$ ls -l
total 664
-rwxr-xr-x 1 ykong ykong 676432 Dec 14 22:48 busybox
lrwxrwxrwx 1 ykong ykong      7 Dec  4 20:22 vi -> busybox

When mounting this image, errors like:
[13667.440498] UBIFS error (pid 429): ubifs_lookup: dead directory entry 'vi', error -22
But 'vi' is not directory.....

It seems OK when "bin" only contains "busybox".

How do you think about it? Thank you.

Whole logs:

root@swi-mdm9x15:/mnt/flash# cd /mnt/ubifs/bin/
[13667.193772] UBIFS error (pid 429): ubifs_check_node: bad magic 0xce703d7f, expected 0x6101831
[13667.202165] UBIFS error (pid 429): ubifs_check_node: bad node at LEB 13:4032
[13667.208574] UBIFS error (pid 429): ubifs_read_node: expected node type 9
[13667.215685] UBIFS error (pid 429): ubifs_check_node: bad magic 0xce703d7f, expected 0x6101831
[13667.224140] UBIFS error (pid 429): ubifs_check_node: bad node at LEB 13:4032
[13667.230762] UBIFS error (pid 429): ubifs_read_node: expected node type 9
[13667.237752] UBIFS error (pid 429): ubifs_check_node: bad magic 0xce7038bf, expected 0x6101831
[13667.246297] UBIFS error (pid 429): ubifs_check_node: bad node at LEB 13:4032
[13667.253256] UBIFS error (pid 429): ubifs_read_node: expected node type 9
[13667.260031] UBIFS error (pid 429): ubifs_check_node: bad magic 0xce7038bf, expected 0x6101831
[13667.268699] UBIFS error (pid 429): ubifs_check_node: bad node at LEB 13:4032
[13667.275505] UBIFS error (pid 429): ubifs_read_node: expected node type 9
[13667.282189] UBIFS error (pid 429): ubifs_iget: failed to read inode 67, error -117
[13667.289514] UBIFS error (pid 429): ubifs_lookup: dead directory entry 'vi', error -117
[13667.298212] UBIFS warning (pid 429): ubifs_ro_mode: switched to read-only mode, error -117
[13667.306087] [<c0015568>] (unwind_backtrace+0x0/0x138) from [<c068f590>] (dump_stack+0x20/0x24)
[13667.314571] [<c068f590>] (dump_stack+0x20/0x24) from [<c025c584>] (ubifs_ro_mode+0x74/0x80)
[13667.322995] [<c025c584>] (ubifs_ro_mode+0x74/0x80) from [<c0257688>] (ubifs_lookup+0xfc/0x150)
[13667.331480] [<c0257688>] (ubifs_lookup+0xfc/0x150) from [<c0133d3c>] (__lookup_hash+0xc0/0xf8)
[13667.339873] [<c0133d3c>] (__lookup_hash+0xc0/0xf8) from [<c0133fe4>] (do_lookup+0x270/0x2b0)
[13667.348632] [<c0133fe4>] (do_lookup+0x270/0x2b0) from [<c0135df8>] (path_lookupat+0x10c/0x700)
[13667.357178] [<c0135df8>] (path_lookupat+0x10c/0x700) from [<c0136418>] (do_path_lookup+0x2c/0x68)
[13667.366029] [<c0136418>] (do_path_lookup+0x2c/0x68) from [<c0137de8>] (user_path_at_empty+0x68/0x98)
[13667.375154] [<c0137de8>] (user_path_at_empty+0x68/0x98) from [<c0137e3c>] (user_path_at+0x24/0x2c)
[13667.384097] [<c0137e3c>] (user_path_at+0x24/0x2c) from [<c012dea4>] (vfs_fstatat+0x40/0x78)
[13667.392337] [<c012dea4>] (vfs_fstatat+0x40/0x78) from [<c012df38>] (vfs_stat+0x2c/0x30)
[13667.400151] [<c012df38>] (vfs_stat+0x2c/0x30) from [<c012e160>] (sys_stat64+0x24/0x40)
[13667.408360] [<c012e160>] (sys_stat64+0x24/0x40) from [<c000e6a0>] (ret_fast_syscall+0x0/0x30)
[13667.416876] UBIFS error (pid 429): ubifs_read_node: bad node type (0 but expected 9)
[13667.424475] UBIFS error (pid 429): ubifs_read_node: bad node at LEB 13:4032, LEB mapping status 1
[13667.433326] UBIFS error (pid 429): ubifs_iget: failed to read inode 67, error -22
[13667.440498] UBIFS error (pid 429): ubifs_lookup: dead directory entry 'vi', error -22
busybox  vi       



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

Hi!

Am 15.12.2014 um 04:30 schrieb Yan Kong:
> Hi Richard,
> 
> The FAE tell me that now mtd driver doesn't support only write OOB area, but not write data area. So mtd_oobtest.

This sentence does not parse.

> But they are not sure if it is related to the UBI error. What do you think about it?

Fact is that mtd_read() returns less bytes than requested. This must not happen and is most likely a driver issue.
I'd start investigating here.
Almost all "UBI issues" I inspect for customers turn out to be plain mtd driver bugs.

> Another thing is that, I tried to enable nandsim in my Kernel, but saw that "Sub-page size" and "OOB size" of nandsim partition are different from local mtd partition's.
> The parameter of nandsim are as follows, which is copied from boot up logs.
> Command of insmod nandsim is:
> modprobe nandsim first_id_byte=0x2c second_id_byte=0xac 
> third_id_byte=0x90 fourth_id_byte=0x26 Is the parameter I used wrong?

If the ID bytes are correct everything work fine.

Thanks,
//richard