* Failure on MTD sub-page test
@ 2016-10-11 11:11 Danesh Daroui
2016-10-14 12:41 ` Artem Bityutskiy
0 siblings, 1 reply; 5+ messages in thread
From: Danesh Daroui @ 2016-10-11 11:11 UTC (permalink / raw)
To: linux-mtd
Hello,
We are using UBIFS which is shipped with the Kernel 2.6.39.4 on a NAND Flash memory. When I run "mtd_debug info /dev/mtd0" following info are shown:
mtd.type = MTD_NANDFLASH
mtd.flags = MTD_CAP_NANDFLASH
mtd.size = 1073741824 (1G)
mtd.erasesize = 524288 (512K)
mtd.writesize = 4096 (4K)
mtd.oobsize = 128
regions = 0
Now the problem is that when I run mtd tests, only read and NAND ECC tests are passed. Then all other tests fail on exactly page 21. For instance this is the output when I run page test:
=================================================
mtd_subpagetest: MTD device: 0
mtd_subpagetest: MTD device size 1073741824, eraseblock size 524288, page size 4096, subpage size 1024, count of eraseblocks 2048, pages per eraseblock 128, OOB size 128
mtd_subpagetest: scanning for bad eraseblocks
mtd_subpagetest: scanned 2048 eraseblocks, 0 are bad
mtd_subpagetest: erasing whole device
mtd_subpagetest: erased 2048 eraseblocks
mtd_subpagetest: writing whole device
mtd_subpagetest: written up to eraseblock 0
mtd_subpagetest: written up to eraseblock 256
mtd_subpagetest: written up to eraseblock 512
mtd_subpagetest: written up to eraseblock 768
mtd_subpagetest: written up to eraseblock 1024
mtd_subpagetest: written up to eraseblock 1280
mtd_subpagetest: written up to eraseblock 1536
mtd_subpagetest: written up to eraseblock 1792
mtd_subpagetest: written 2048 eraseblocks
mtd_subpagetest: verifying all eraseblocks
mtd_subpagetest: verified up to eraseblock 0
mtd_subpagetest: verified up to eraseblock 256
mtd_subpagetest: verified up to eraseblock 512
mtd_subpagetest: verified up to eraseblock 768
mtd_subpagetest: verified up to eraseblock 1024
mtd_subpagetest: verified up to eraseblock 1280
mtd_subpagetest: verified up to eraseblock 1536
mtd_subpagetest: verified up to eraseblock 1792
mtd_subpagetest: verified 2048 eraseblocks
mtd_subpagetest: erasing whole device
mtd_subpagetest: erased 2048 eraseblocks
mtd_subpagetest: verifying all eraseblocks for 0xff
mtd_subpagetest: verified up to eraseblock 0
mtd_subpagetest: verified up to eraseblock 256
mtd_subpagetest: verified up to eraseblock 512
mtd_subpagetest: verified up to eraseblock 768
mtd_subpagetest: verified up to eraseblock 1024
mtd_subpagetest: verified up to eraseblock 1280
mtd_subpagetest: verified up to eraseblock 1536
mtd_subpagetest: verified up to eraseblock 1792
UBIFS error (pid 4243): ubifs_read_node: bad node type (255 but expected 1)
UBIFS error (pid 4243): ubifs_read_node: bad node at LEB 30:98088, LEB mapping status 1
UBIFS error (pid 4243): do_readpage: cannot read page 21 of inode 791, error -22
Signal 7 (BUS) caught by ps (procps version 3.2.8).
Please send bug reports to <feedback@lists.sf.net> or <albert@users.sf.net>
UBIFS error (pid 4245): ubifs_read_node: bad node type (255 but expected 9)
UBIFS error (pid 4245): ubifs_read_node: bad node at LEB 12:458808, LEB mapping status 1
UBIFS error (pid 4245): ubifs_iget: failed to read inode 1470, error -22
UBIFS error (pid 4245): ubifs_lookup: dead directory entry 'free', error -22
UBIFS error (pid 4246): ubifs_read_node: bad node type (255 but expected 9)
UBIFS error (pid 4246): ubifs_read_node: bad node at LEB 12:458808, LEB mapping status 1
UBIFS error (pid 4246): ubifs_iget: failed to read inode 1470, error -22
UBIFS error (pid 4246): ubifs_lookup: dead directory entry 'free', error -22
sh: free: Invalid argument
mtd_subpagetest: verified 2048 eraseblocks
mtd_subpagetest: writing whole device
mtd_subpagetest: written up to eraseblock 0
mtd_subpagetest: written up to eraseblock 256
mtd_subpagetest: written up to eraseblock 512
mtd_subpagetest: written up to eraseblock 768
mtd_subpagetest: written up to eraseblock 1024
mtd_subpagetest: written up to eraseblock 1280
mtd_subpagetest: written up to eraseblock 1536
mtd_subpagetest: written up to eraseblock 1792
mtd_subpagetest: written 2048 eraseblocks
mtd_subpagetest: verifying all eraseblocks
mtd_subpagetest: verified up to eraseblock 0
mtd_subpagetest: ECC correction at 0x300400
mtd_subpagetest: ECC correction at 0x3d80400
mtd_subpagetest: verified up to eraseblock 256
mtd_subpagetest: verified up to eraseblock 512
mtd_subpagetest: ECC correction at 0x13500000
mtd_subpagetest: verified up to eraseblock 768
mtd_subpagetest: verified up to eraseblock 1024
mtd_subpagetest: verified up to eraseblock 1280
mtd_subpagetest: verified up to eraseblock 1536
mtd_subpagetest: verified up to eraseblock 1792
mtd_subpagetest: ECC correction at 0x3ba00400
mtd_subpagetest: verified 2048 eraseblocks
mtd_subpagetest: erasing whole device
mtd_subpagetest: erased 2048 eraseblocks
mtd_subpagetest: verifying all eraseblocks for 0xff
mtd_subpagetest: verified up to eraseblock 0
mtd_subpagetest: verified up to eraseblock 256
mtd_subpagetest: verified up to eraseblock 512
mtd_subpagetest: verified up to eraseblock 768
UBIFS error (pid 4572): ubifs_read_node: bad node type (255 but expected 1)
UBIFS error (pid 4572): ubifs_read_node: bad node at LEB 30:98088, LEB mapping status 1
UBIFS error (pid 4572): do_readpage: cannot read page 21 of inode 791, error -22
Signal 7 (BUS) caught by ps (procps version 3.2.8).
Please send bug reports to <feedback@lists.sf.net> or <albert@users.sf.net>
UBIFS error (pid 4576): ubifs_read_node: bad node type (255 but expected 9)
UBIFS error (pid 4576): ubifs_read_node: bad node at LEB 12:458808, LEB mapping status 1
UBIFS error (pid 4576): ubifs_iget: failed to read inode 1470, error -22
UBIFS error (pid 4576): ubifs_lookup: dead directory entry 'free', error -22
UBIFS error (pid 4581): ubifs_read_node: bad node type (255 but expected 9)
UBIFS error (pid 4581): ubifs_read_node: bad node at LEB 12:458808, LEB mapping status 1
UBIFS error (pid 4581): ubifs_iget: failed to read inode 1470, error -22
UBIFS error (pid 4581): ubifs_lookup: dead directory entry 'free', error -22
sh: free: Invalid argument
mtd_subpagetest: verified up to eraseblock 1024
mtd_subpagetest: verified up to eraseblock 1280
mtd_subpagetest: verified up to eraseblock 1536
mtd_subpagetest: verified up to eraseblock 1792
mtd_subpagetest: verified 2048 eraseblocks
mtd_subpagetest: finished with 0 errors
=================================================
Despite 0 errors reported at the end of the test, UBIFS error has happened at least twice during the test exactly at page 21. This even worse when I run page test where the test is interrupted with device boot in the middle of the test which prevents the test to be done, as the log shows:
=================================================
mtd_pagetest: MTD device: 0
mtd_pagetest: MTD device size 1073741824, eraseblock size 524288, page size 4096, count of eraseblocks 2048, pages per eraseblock 128, OOB size 128
mtd_pagetest: scanning for bad eraseblocks
mtd_pagetest: scanned 2048 eraseblocks, 0 are bad
mtd_pagetest: erasing whole device
mtd_pagetest: erased 2048 eraseblocks
mtd_pagetest: writing whole device
mtd_pagetest: written up to eraseblock 0
mtd_pagetest: written up to eraseblock 256
mtd_pagetest: written up to eraseblock 512
UBIFS error (pid 2404): ubifs_read_node: bad node type (255 but expected 1)
UBIFS error (pid 2404): ubifs_read_node: bad node at LEB 30:98088, LEB mapping status 1
UBIFS error (pid 2404): do_readpage: cannot read page 21 of inode 791, error -22
UBIFS error (pid 2404): ubifs_read_node: bad node type (255 but expected 1)
UBIFS error (pid 2404): ubifs_read_node: bad node at LEB 30:98088, LEB mapping status 1
UBIFS error (pid 2404): do_readpage: cannot read page 21 of inode 791, error -22
Signal 7 (BUS) caught by ps (procps version 3.2.8).
Please send bug reports to <feedback@lists.sf.net> or <albert@users.sf.net>
UBIFS error (pid 2406): ubifs_read_node: bad node type (255 but expected 9)
UBIFS error (pid 2406): ubifs_read_node: bad node at LEB 12:463712, LEB mapping status 1
UBIFS error (pid 2406): ubifs_iget: failed to read inode 1470, error -22
UBIFS error (pid 2406): ubifs_lookup: dead directory entry 'free', error -22
UBIFS warning (pid 2406): ubifs_ro_mode: switched to read-only mode, error -22
UBIFS error (pid 2407): ubifs_read_node: bad node type (255 but expected 9)
UBIFS error (pid 2407): ubifs_read_node: bad node at LEB 12:463712, LEB mapping status 1
UBIFS error (pid 2407): ubifs_iget: failed to read inode 1470, error -22
UBIFS error (pid 2407): ubifs_lookup: dead directory entry 'free', error -22
sh: free: Invalid argument
mtd_pagetest: written up to eraseblock 768
mtd_pagetest: written up to eraseblock 1024
mtd_pagetest: written up to eraseblock 1280
mtd_pagetest: written up to eraseblock 1536
mtd_pagetest: written up to eraseblock 1792
mtd_pagetest: written 2048 eraseblocks
mtd_pagetest: verifying all eraseblocks
mtd_pagetest: verified up to eraseblock 0
RomBOOT
Since we are using a quite old and outdated kernel version i.e. 2.6.39.4, I am wondering whether a kernel update would fix this problem or not. Because kernel update is a quite big task due to incompatibilities that might happen, then we would prefer to know if the source of the problem is detectable and if there is any patch that we can use to pass all the tests with the current kernel or if we can use the latest version of UIFS without updating the kernel.
Sincerely,
Danesh Daroui
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Failure on MTD sub-page test
2016-10-11 11:11 Failure on MTD sub-page test Danesh Daroui
@ 2016-10-14 12:41 ` Artem Bityutskiy
2016-10-14 14:13 ` Danesh Daroui
0 siblings, 1 reply; 5+ messages in thread
From: Artem Bityutskiy @ 2016-10-14 12:41 UTC (permalink / raw)
To: Danesh Daroui, linux-mtd
On Tue, 2016-10-11 at 11:11 +0000, Danesh Daroui wrote:
> Hello,
>
> We are using UBIFS which is shipped with the Kernel 2.6.39.4 on a
> NAND Flash memory. When I run "mtd_debug info /dev/mtd0" following
> info are shown:
>
> mtd.type = MTD_NANDFLASH
> mtd.flags = MTD_CAP_NANDFLASH
> mtd.size = 1073741824 (1G)
> mtd.erasesize = 524288 (512K)
> mtd.writesize = 4096 (4K)
> mtd.oobsize = 128
> regions = 0
>
> Now the problem is that when I run mtd tests, only read and NAND ECC
> tests are passed. Then all other tests fail on exactly page 21. For
> instance this is the output when I run page test:
If mtd tests do not work, you need to focus on your MTD drivers and fix
them.
> =================================================
> mtd_subpagetest: MTD device: 0
> mtd_subpagetest: MTD device size 1073741824, eraseblock size 524288,
> page size 4096, subpage size 1024, count of eraseblocks 2048, pages
... snip ...
> mtd_subpagetest: verified up to eraseblock 1280
> mtd_subpagetest: verified up to eraseblock 1536
> mtd_subpagetest: verified up to eraseblock 1792
> UBIFS error (pid 4243): ubifs_read_node: bad node type (255 but
> expected 1)
> UBIFS error (pid 4243): ubifs_read_node: bad node at LEB 30:98088,
> LEB mapping status 1
> UBIFS error (pid 4243): do_readpage: cannot read page 21 of inode
> 791, error -22
This is a bit confusing - why messages go together. Do you run mtd
tests and also have the same mtd device mounted at the same time?
The tests hammer the MTD device directly, they do not go through
UBI/UBIFS. So make sure UBI/UBIFS are not using the MTD device that you
are testing.
Artem.
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Failure on MTD sub-page test
2016-10-14 12:41 ` Artem Bityutskiy
@ 2016-10-14 14:13 ` Danesh Daroui
2016-10-14 14:38 ` Artem Bityutskiy
2016-10-24 11:58 ` Danesh Daroui
0 siblings, 2 replies; 5+ messages in thread
From: Danesh Daroui @ 2016-10-14 14:13 UTC (permalink / raw)
To: dedekind1, linux-mtd
Hi Artem,
Thanks for your reply. I can unmount the device and run the tests, but then how can we make sure whether the problem is in UBI/UBIFS layers or only MTD layer? Anyway, if we update the kernel, then both MTD drivers and UBI/UBIFS will be updated, am I right?
Regards,
Danesh Daroui
-----Original Message-----
From: Artem Bityutskiy [mailto:dedekind1@gmail.com]
Sent: den 14 oktober 2016 14:41
To: Danesh Daroui <Danesh.Daroui@ascom.com>; linux-mtd@lists.infradead.org
Subject: Re: Failure on MTD sub-page test
On Tue, 2016-10-11 at 11:11 +0000, Danesh Daroui wrote:
> Hello,
>
> We are using UBIFS which is shipped with the Kernel 2.6.39.4 on a NAND
> Flash memory. When I run "mtd_debug info /dev/mtd0" following info are
> shown:
>
> mtd.type = MTD_NANDFLASH
> mtd.flags = MTD_CAP_NANDFLASH
> mtd.size = 1073741824 (1G)
> mtd.erasesize = 524288 (512K)
> mtd.writesize = 4096 (4K)
> mtd.oobsize = 128
> regions = 0
>
> Now the problem is that when I run mtd tests, only read and NAND ECC
> tests are passed. Then all other tests fail on exactly page 21. For
> instance this is the output when I run page test:
If mtd tests do not work, you need to focus on your MTD drivers and fix them.
> =================================================
> mtd_subpagetest: MTD device: 0
> mtd_subpagetest: MTD device size 1073741824, eraseblock size 524288,
> page size 4096, subpage size 1024, count of eraseblocks 2048, pages
... snip ...
> mtd_subpagetest: verified up to eraseblock 1280
> mtd_subpagetest: verified up to eraseblock 1536
> mtd_subpagetest: verified up to eraseblock 1792 UBIFS error (pid
> 4243): ubifs_read_node: bad node type (255 but expected 1) UBIFS error
> (pid 4243): ubifs_read_node: bad node at LEB 30:98088, LEB mapping
> status 1 UBIFS error (pid 4243): do_readpage: cannot read page 21 of
> inode 791, error -22
This is a bit confusing - why messages go together. Do you run mtd tests and also have the same mtd device mounted at the same time?
The tests hammer the MTD device directly, they do not go through UBI/UBIFS. So make sure UBI/UBIFS are not using the MTD device that you are testing.
Artem.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Failure on MTD sub-page test
2016-10-14 14:13 ` Danesh Daroui
@ 2016-10-14 14:38 ` Artem Bityutskiy
2016-10-24 11:58 ` Danesh Daroui
1 sibling, 0 replies; 5+ messages in thread
From: Artem Bityutskiy @ 2016-10-14 14:38 UTC (permalink / raw)
To: Danesh Daroui, linux-mtd
On Fri, 2016-10-14 at 14:13 +0000, Danesh Daroui wrote:
> Hi Artem,
>
> Thanks for your reply. I can unmount the device and run the tests,
> but then how can we make sure whether the problem is in UBI/UBIFS
> layers or only MTD layer? Anyway, if we update the kernel, then both
> MTD drivers and UBI/UBIFS will be updated, am I right?
You are experiencing some issues with UBIFS, I suppose. Naturally, you
want to fix it.
But the SW you are dealing with is sandwich, and you want to narrow
down the problem to a specific layer, if possible.
The first step we usually recommend to do is to start validating the
low level - MTD. You use MTD tests for that. If they fail, you know
there is something wrong at this layer, and you go and fix that. If
they do not fail, the problem is probably somewhere above MTD.
Artem.
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Failure on MTD sub-page test
2016-10-14 14:13 ` Danesh Daroui
2016-10-14 14:38 ` Artem Bityutskiy
@ 2016-10-24 11:58 ` Danesh Daroui
1 sibling, 0 replies; 5+ messages in thread
From: Danesh Daroui @ 2016-10-24 11:58 UTC (permalink / raw)
To: Danesh Daroui, dedekind1, linux-mtd
Hi Artem,
I ran the tests this time without mouting the file system and now all tests except OOB has been passed. The result for OOB test is:
mtd_oobtest: MTD device: 0
mtd_oobtest: MTD device size 1073741824, eraseblock size 524288, page size 4096, count of eraseblocks 2048, pages per eraseblock 128, OOB size 128
mtd_oobtest: scanning for bad eraseblocks
mtd_oobtest: scanned 2048 eraseblocks, 0 are bad
mtd_oobtest: test 1 of 5
mtd_oobtest: erasing whole device
mtd_oobtest: erased 2048 eraseblocks
mtd_oobtest: writing OOBs of whole device
mtd_oobtest: written up to eraseblock 0
mtd_oobtest: written up to eraseblock 256
mtd_oobtest: written up to eraseblock 512
mtd_oobtest: written up to eraseblock 768
mtd_oobtest: written up to eraseblock 1024
mtd_oobtest: written up to eraseblock 1280
mtd_oobtest: written up to eraseblock 1536
mtd_oobtest: written up to eraseblock 1792
mtd_oobtest: written 2048 eraseblocks
mtd_oobtest: verifying all eraseblocks
mtd_oobtest: verified up to eraseblock 0
mtd_oobtest: verified up to eraseblock 256
mtd_oobtest: verified up to eraseblock 512
mtd_oobtest: verified up to eraseblock 768
mtd_oobtest: verified up to eraseblock 1024
mtd_oobtest: verified up to eraseblock 1280
mtd_oobtest: verified up to eraseblock 1536
mtd_oobtest: verified up to eraseblock 1792
mtd_oobtest: verified 2048 eraseblocks
mtd_oobtest: test 2 of 5
mtd_oobtest: erasing whole device
mtd_oobtest: erased 2048 eraseblocks
mtd_oobtest: writing OOBs of whole device
mtd_oobtest: written up to eraseblock 0
mtd_oobtest: written up to eraseblock 256
mtd_oobtest: written up to eraseblock 512
mtd_oobtest: written up to eraseblock 768
mtd_oobtest: written up to eraseblock 1024
mtd_oobtest: written up to eraseblock 1280
mtd_oobtest: written up to eraseblock 1536
mtd_oobtest: written up to eraseblock 1792
mtd_oobtest: written 2048 eraseblocks
mtd_oobtest: verifying all eraseblocks
mtd_oobtest: verified up to eraseblock 0
mtd_oobtest: error: verify failed at 0x5300000
mtd_oobtest: verified up to eraseblock 256
mtd_oobtest: verified up to eraseblock 512
mtd_oobtest: verified up to eraseblock 768
mtd_oobtest: verified up to eraseblock 1024
mtd_oobtest: verified up to eraseblock 1280
mtd_oobtest: verified up to eraseblock 1536
mtd_oobtest: verified up to eraseblock 1792
mtd_oobtest: verified 2048 eraseblocks
mtd_oobtest: test 3 of 5
mtd_oobtest: erasing whole device
mtd_oobtest: erased 2048 eraseblocks
mtd_oobtest: writing OOBs of whole device
mtd_oobtest: written up to eraseblock 0
mtd_oobtest: written up to eraseblock 256
mtd_oobtest: written up to eraseblock 512
mtd_oobtest: written up to eraseblock 768
mtd_oobtest: written up to eraseblock 1024
mtd_oobtest: written up to eraseblock 1280
mtd_oobtest: written up to eraseblock 1536
mtd_oobtest: written up to eraseblock 1792
mtd_oobtest: written 2048 eraseblocks
mtd_oobtest: verifying all eraseblocks
mtd_oobtest: verified up to eraseblock 0
mtd_oobtest: verified up to eraseblock 256
mtd_oobtest: verified up to eraseblock 512
mtd_oobtest: verified up to eraseblock 768
mtd_oobtest: verified up to eraseblock 1024
mtd_oobtest: verified up to eraseblock 1280
mtd_oobtest: verified up to eraseblock 1536
mtd_oobtest: verified up to eraseblock 1792
mtd_oobtest: verified 2048 eraseblocks
mtd_oobtest: test 4 of 5
mtd_oobtest: erasing whole device
mtd_oobtest: erased 2048 eraseblocks
mtd_oobtest: attempting to start write past end of OOB
mtd_oobtest: an error is expected...
mtd_oobtest: error occurred as expected
mtd_oobtest: attempting to start read past end of OOB
mtd_oobtest: an error is expected...
mtd_oobtest: error occurred as expected
mtd_oobtest: attempting to write past end of device
mtd_oobtest: an error is expected...
mtd_oobtest: error occurred as expected
mtd_oobtest: attempting to read past end of device
mtd_oobtest: an error is expected...
mtd_oobtest: error occurred as expected
mtd_oobtest: attempting to write past end of device
mtd_oobtest: an error is expected...
mtd_oobtest: error occurred as expected
mtd_oobtest: attempting to read past end of device
mtd_oobtest: an error is expected...
mtd_oobtest: error occurred as expected
mtd_oobtest: test 5 of 5
mtd_oobtest: erasing whole device
mtd_oobtest: erased 2048 eraseblocks
mtd_oobtest: writing OOBs of whole device
mtd_oobtest: written up to eraseblock 0
mtd_oobtest: written up to eraseblock 0
mtd_oobtest: written up to eraseblock 256
mtd_oobtest: written up to eraseblock 256
mtd_oobtest: written up to eraseblock 512
mtd_oobtest: written up to eraseblock 512
mtd_oobtest: written up to eraseblock 768
mtd_oobtest: written up to eraseblock 768
mtd_oobtest: written up to eraseblock 1024
mtd_oobtest: written up to eraseblock 1024
mtd_oobtest: written up to eraseblock 1280
mtd_oobtest: written up to eraseblock 1280
mtd_oobtest: written up to eraseblock 1536
mtd_oobtest: written up to eraseblock 1536
mtd_oobtest: written up to eraseblock 1792
mtd_oobtest: written up to eraseblock 1792
mtd_oobtest: written 2047 eraseblocks
mtd_oobtest: verifying all eraseblocks
mtd_oobtest: verified up to eraseblock 0
mtd_oobtest: verified up to eraseblock 256
mtd_oobtest: verified up to eraseblock 512
mtd_oobtest: verified up to eraseblock 768
mtd_oobtest: verified up to eraseblock 1024
mtd_oobtest: verified up to eraseblock 1280
mtd_oobtest: verified up to eraseblock 1536
mtd_oobtest: verified up to eraseblock 1792
mtd_oobtest: verified 2047 eraseblocks
mtd_oobtest: finished with 1 errors
The interesting thing is that the file system is forced to switch to read-only mode at startup due to checksum error and some corrupted data that cannot be verified. Now my question is, can failing OOB test explain this failure? I mean, if OOB test fails (like our case) then it is very likely that the device experience data integrity problem at start up since OOB or Out Of Band area contains meta data info for the file system and is the first part that is read and verified during start up so if it fails, it can force the file system into read-only mode to prevent further data corruption. Am I right?
Regards,
Danesh Daroui
-----Original Message-----
From: linux-mtd [mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of Danesh Daroui
Sent: den 14 oktober 2016 16:14
To: dedekind1@gmail.com; linux-mtd@lists.infradead.org
Subject: RE: Failure on MTD sub-page test
Hi Artem,
Thanks for your reply. I can unmount the device and run the tests, but then how can we make sure whether the problem is in UBI/UBIFS layers or only MTD layer? Anyway, if we update the kernel, then both MTD drivers and UBI/UBIFS will be updated, am I right?
Regards,
Danesh Daroui
-----Original Message-----
From: Artem Bityutskiy [mailto:dedekind1@gmail.com]
Sent: den 14 oktober 2016 14:41
To: Danesh Daroui <Danesh.Daroui@ascom.com>; linux-mtd@lists.infradead.org
Subject: Re: Failure on MTD sub-page test
On Tue, 2016-10-11 at 11:11 +0000, Danesh Daroui wrote:
> Hello,
>
> We are using UBIFS which is shipped with the Kernel 2.6.39.4 on a NAND
> Flash memory. When I run "mtd_debug info /dev/mtd0" following info are
> shown:
>
> mtd.type = MTD_NANDFLASH
> mtd.flags = MTD_CAP_NANDFLASH
> mtd.size = 1073741824 (1G)
> mtd.erasesize = 524288 (512K)
> mtd.writesize = 4096 (4K)
> mtd.oobsize = 128
> regions = 0
>
> Now the problem is that when I run mtd tests, only read and NAND ECC
> tests are passed. Then all other tests fail on exactly page 21. For
> instance this is the output when I run page test:
If mtd tests do not work, you need to focus on your MTD drivers and fix them.
> =================================================
> mtd_subpagetest: MTD device: 0
> mtd_subpagetest: MTD device size 1073741824, eraseblock size 524288,
> page size 4096, subpage size 1024, count of eraseblocks 2048, pages
... snip ...
> mtd_subpagetest: verified up to eraseblock 1280
> mtd_subpagetest: verified up to eraseblock 1536
> mtd_subpagetest: verified up to eraseblock 1792 UBIFS error (pid
> 4243): ubifs_read_node: bad node type (255 but expected 1) UBIFS error
> (pid 4243): ubifs_read_node: bad node at LEB 30:98088, LEB mapping
> status 1 UBIFS error (pid 4243): do_readpage: cannot read page 21 of
> inode 791, error -22
This is a bit confusing - why messages go together. Do you run mtd tests and also have the same mtd device mounted at the same time?
The tests hammer the MTD device directly, they do not go through UBI/UBIFS. So make sure UBI/UBIFS are not using the MTD device that you are testing.
Artem.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-10-24 11:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-11 11:11 Failure on MTD sub-page test Danesh Daroui
2016-10-14 12:41 ` Artem Bityutskiy
2016-10-14 14:13 ` Danesh Daroui
2016-10-14 14:38 ` Artem Bityutskiy
2016-10-24 11:58 ` Danesh Daroui
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.