All of lore.kernel.org
 help / color / mirror / Atom feed
* UBIFS recovery fail after power-cut
@ 2012-04-04 12:09 b w
  2012-04-13 16:59 ` Artem Bityutskiy
  0 siblings, 1 reply; 4+ messages in thread
From: b w @ 2012-04-04 12:09 UTC (permalink / raw)
  To: linux-mtd

Hello list,
        Using kernel 2.6.32 (which have already apply the latest UBIFS
and UBI patches),nor flash.
UBIFS mount fail fail after an power cut due to recovery . Recovery
failed because after power cut ,the flash image is like this:
02ab3eb0h: 00 00 00 00 00 00 00 00 00 E6 0C 00 11 00 00 00
02ab3ec0h: 31 18 10 06 04 80 DE AF FF FF FF FF FF FF FF FF
02ab3ed0h: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
02ab3ee0h: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
02ab3ef0h: 05 89 AB CD EF 89 AB CD EF 20 00 00 00 00 00 00
02ab3f00h: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
First,when ubifs_recover_leb call ubifs_scan_a_node,and found that in
0x02ab3ec8h
had a bad node type,so ubifs_scan_a_node return SCANNED_A_CORRUPT_NODE.
Then in ubifs_recover_leb,when call no_more_nodes this function return
0 (which i think
should be return 1).At last recovery failed,so mount failed too.

The flash device is S29GL01GP12TFI01. I try to reproduce the flash
image by power down,but
not success yet. I reproduce this problem using the flash image which
i dumped after the first problem happened.
I do not know how can reproduce this problem by power down. And also i
know is that this flash internal buffer size is 64 bytes.

I think in this situation, function no_more_nodes not work
correctly,we should fix it.

error log:
[   35.290516] UBIFS error (pid 1110): ubifs_check_node: bad node type 255
[   35.294516] UBIFS error (pid 1110): ubifs_check_node: bad node at
LEB 388:81472
[   35.302725] Call Trace:
[   35.302725]  [<c1156ec3>] ubifs_check_node+0x21d/0x22e
[   35.307600]  [<c115d6db>] ubifs_scan_a_node+0x139/0x297
[   35.311600]  [<c116d894>] ubifs_recover_leb+0x12a/0x63e
[   35.311600]  [<c108fdb4>] ? __slab_free+0x3d/0x1db
[   35.315337]  [<c115e60e>] ubifs_replay_journal+0x7f5/0x14b7
[   35.319337]  [<c1169a1c>] ? ubifs_lpt_init+0x528/0x8b2
[   35.319337]  [<c1153471>] ubifs_fill_super+0xb31/0x198b
[   35.323828]  [<c11553bc>] ubifs_get_sb+0x40f/0x493
[   35.327828]  [<c10952d9>] vfs_kern_mount+0x80/0x115
[   35.330298]  [<c1095415>] do_kern_mount+0x32/0xbe
[   35.330298]  [<c10a55e0>] do_mount+0x550/0x5af
[   35.333543]  [<c1399518>] ? do_page_fault+0x0/0x26e
[   35.333543]  [<c107c544>] ? strndup_user+0x40/0x5f
[   35.338891]  [<c10a56a0>] sys_mount+0x61/0x8f
[   35.342891]  [<c1002b64>] sysenter_do_call+0x12/0x22
[   35.345633] found corruption - -3
[   35.345633] UBIFS error (pid 1110): ubifs_check_node: bad node type 255
[   35.350654] UBIFS error (pid 1110): ubifs_check_node: bad node at
LEB 388:81472
[   35.359341] Call Trace:
[   35.359341]  [<c1156ec3>] ubifs_check_node+0x21d/0x22e
[   35.363515]  [<c116d99b>] ubifs_recover_leb+0x231/0x63e
[   35.367515]  [<c108fdb4>] ? __slab_free+0x3d/0x1db
[   35.367515]  [<c115e60e>] ubifs_replay_journal+0x7f5/0x14b7
[   35.371324]  [<c1169a1c>] ? ubifs_lpt_init+0x528/0x8b2
[   35.375324]  [<c1153471>] ubifs_fill_super+0xb31/0x198b
[   35.375324]  [<c11553bc>] ubifs_get_sb+0x40f/0x493
[   35.379321]  [<c10952d9>] vfs_kern_mount+0x80/0x115
[   35.383321]  [<c1095415>] do_kern_mount+0x32/0xbe
[   35.383321]  [<c10a55e0>] do_mount+0x550/0x5af
[   35.386657]  [<c1399518>] ? do_page_fault+0x0/0x26e
[   35.390657]  [<c107c544>] ? strndup_user+0x40/0x5f
[   35.390657]  [<c10a56a0>] sys_mount+0x61/0x8f
[   35.393861]  [<c1002b64>] sysenter_do_call+0x12/0x22
[   35.393861] unexpected bad common header at 388:81472
[   35.398954] UBIFS error (pid 1110): ubifs_recover_leb: corruptio -3
[   35.407615] UBIFS error (pid 1110): ubifs_check_node: bad node type 255
[   35.409498] UBIFS error (pid 1110): ubifs_check_node: bad node at
LEB 388:81472
[   35.417522] Call Trace:
[   35.417522]  [<c1156ec3>] ubifs_check_node+0x21d/0x22e
[   35.421699]  [<c115d6db>] ubifs_scan_a_node+0x139/0x297
[   35.425699]  [<c116dd3d>] ubifs_recover_leb+0x5d3/0x63e
[   35.425699]  [<c108fdb4>] ? __slab_free+0x3d/0x1db
[   35.429345]  [<c115e60e>] ubifs_replay_journal+0x7f5/0x14b7
[   35.429345]  [<c1169a1c>] ? ubifs_lpt_init+0x528/0x8b2
[   35.434631]  [<c1153471>] ubifs_fill_super+0xb31/0x198b
[   35.434631]  [<c11553bc>] ubifs_get_sb+0x40f/0x493
[   35.439765]  [<c10952d9>] vfs_kern_mount+0x80/0x115
[   35.443765]  [<c1095415>] do_kern_mount+0x32/0xbe
[   35.443765]  [<c10a55e0>] do_mount+0x550/0x5af
[   35.447007]  [<c1399518>] ? do_page_fault+0x0/0x26e
[   35.447007]  [<c107c544>] ? strndup_user+0x40/0x5f
[   35.451007]  [<c10a56a0>] sys_mount+0x61/0x8f
[   35.454462]  [<c1002b64>] sysenter_do_call+0x12/0x22
[   35.458825] UBIFS error (pid 1110): ubifs_scanned_corruption:
corruption at LEB 388:81472
[   35.463297] UBIFS error (pid 1110): ubifs_scanned_corruption: first
8192 bytes from LEB 388:81472
[   35.481198] UBIFS error (pid 1110): ubifs_recover_leb: LEB 388
scanning failed
mount: mounting ubi0 on /mtd3 failed: Structure needs cleaning

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: UBIFS recovery fail after power-cut
  2012-04-04 12:09 UBIFS recovery fail after power-cut b w
@ 2012-04-13 16:59 ` Artem Bityutskiy
  2012-04-17 13:03   ` b w
  0 siblings, 1 reply; 4+ messages in thread
From: Artem Bityutskiy @ 2012-04-13 16:59 UTC (permalink / raw)
  To: b w; +Cc: linux-mtd

[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]

On Wed, 2012-04-04 at 20:09 +0800, b w wrote:
> Hello list,
>         Using kernel 2.6.32 (which have already apply the latest UBIFS
> and UBI patches),nor flash.
> UBIFS mount fail fail after an power cut due to recovery . Recovery
> failed because after power cut ,the flash image is like this:
> 02ab3eb0h: 00 00 00 00 00 00 00 00 00 E6 0C 00 11 00 00 00
> 02ab3ec0h: 31 18 10 06 04 80 DE AF FF FF FF FF FF FF FF FF
> 02ab3ed0h: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> 02ab3ee0h: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> 02ab3ef0h: 05 89 AB CD EF 89 AB CD EF 20 00 00 00 00 00 00
> 02ab3f00h: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
> First,when ubifs_recover_leb call ubifs_scan_a_node,and found that in
> 0x02ab3ec8h
> had a bad node type,so ubifs_scan_a_node return SCANNED_A_CORRUPT_NODE.

OK.

> Then in ubifs_recover_leb,when call no_more_nodes this function return
> 0 (which i think
> should be return 1).At last recovery failed,so mount failed too.

We have this code in that function:

        /* Check for empty space after the corrupt node's common header */
        skip = ALIGN(offs + UBIFS_CH_SZ, c->max_write_size) - offs;
        if (is_empty(buf + skip, len - skip))
                return 1;


UBIFS_CH_SZ is 64, c->max_write_size is 64, then ALIGN(offs +
UBIFS_CH_SZ, c->max_write_size) should be 0x2ab3f40, which points to the
area with all 0xFFs, so 'is_empty' should return 1.

Did you check that your c->max_write_size is 64?

Preserve the image for investigations.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: UBIFS recovery fail after power-cut
  2012-04-13 16:59 ` Artem Bityutskiy
@ 2012-04-17 13:03   ` b w
  2012-04-25 15:03     ` Artem Bityutskiy
  0 siblings, 1 reply; 4+ messages in thread
From: b w @ 2012-04-17 13:03 UTC (permalink / raw)
  To: dedekind1; +Cc: linux-mtd

> On Wed, 2012-04-04 at 20:09 +0800, b w wrote:
>
>> Then in ubifs_recover_leb,when call no_more_nodes this function return
>> 0 (which i think
>> should be return 1).At last recovery failed,so mount failed too.
>
> We have this code in that function:
>
>        /* Check for empty space after the corrupt node's common header */
>        skip = ALIGN(offs + UBIFS_CH_SZ, c->max_write_size) - offs;
>        if (is_empty(buf + skip, len - skip))
>                return 1;
>
> UBIFS_CH_SZ is 64, c->max_write_size is 64, then ALIGN(offs +
> UBIFS_CH_SZ, c->max_write_size) should be 0x2ab3f40, which points to the
> area with all 0xFFs, so 'is_empty' should return 1.
>
> Did you check that your c->max_write_size is 64?
>
> Preserve the image for investigations.
>

Thank you very much. I do not apply this patch: "UBIFS: use
max_write_size during recovery". So the code is "skip = ALIGN(offs +
UBIFS_CH_SZ, c->min_io_size) - offs;" the c->min_io_size is 8. When i
modify MTD/UBI/UBIFS and apply that patch,use  c->max_write_size
instead,this problem is solved.I think that patch not just an optimize
but fix this problem. Should we use "fix" in the title of that patch?
By the way, in my machine UBIFS_CH_SZ is 24 not 64.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: UBIFS recovery fail after power-cut
  2012-04-17 13:03   ` b w
@ 2012-04-25 15:03     ` Artem Bityutskiy
  0 siblings, 0 replies; 4+ messages in thread
From: Artem Bityutskiy @ 2012-04-25 15:03 UTC (permalink / raw)
  To: b w; +Cc: linux-mtd

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

On Tue, 2012-04-17 at 21:03 +0800, b w wrote:
> Thank you very much. I do not apply this patch: "UBIFS: use
> max_write_size during recovery". So the code is "skip = ALIGN(offs +
> UBIFS_CH_SZ, c->min_io_size) - offs;" the c->min_io_size is 8. When i
> modify MTD/UBI/UBIFS and apply that patch,use  c->max_write_size
> instead,this problem is solved.I think that patch not just an optimize
> but fix this problem. Should we use "fix" in the title of that patch?
> By the way, in my machine UBIFS_CH_SZ is 24 not 64.

Good to know that the issue is solved. WRT to re-naming the patch title
- may be you are right, but it is too late now.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-04-25 15:03 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-04 12:09 UBIFS recovery fail after power-cut b w
2012-04-13 16:59 ` Artem Bityutskiy
2012-04-17 13:03   ` b w
2012-04-25 15:03     ` Artem Bityutskiy

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.