Estou desenvolvendo um aplicativo Linux embarcado usando o micro2440 da friendlyARM. Ele roda em um processador ARM Samsung s3c2440 e usa squashfs em seu flash NAND.
Recentemente, alguns flash blocks ficaram ruins. O u-Boot localiza-os corretamente e cria uma tabela de blocos danificados com os deslocamentos dados pelo comando nand bad:
Device 0 bad blocks:
01340000
0abc0000
0f080000
0ff80000
0ffa0000
0ffc0000
0ffe0000
Quando eu tento inicializar o kernel, ele verifica corretamente os blocos defeituosos e cria sua tabela de blocos danificados, como visto nas seguintes mensagens:
Scanning device for bad blocks
Bad eraseblock 154 at 0x000001340000
Bad eraseblock 1374 at 0x00000abc0000
Bad eraseblock 1924 at 0x00000f080000
Mas quando chega a hora de o kernel montar o sistema de arquivos na partição onde o bloco defeituoso ocorre em 0x000001340000, parece impossível pular os blocos defeituosos e então entra em pânico. As mensagens de erro dadas foram:
SQUASHFS error: squashfs_read_data failed to read block 0xd0e24b
SQUASHFS error: Unable to read metadata cache entry [d0e24b]
SQUASHFS error: Unable to read inode 0x3d1d0f68
------------[ cut here ]------------
WARNING: at fs/inode.c:712 unlock_new_inode+0x20/0x3c()
Modules linked in:
[<c0037750>] (unwind_backtrace+0x0/0xcc) from [<c0044994>] (warn_slowpath_null+0x34/0x4c)
[<c0044994>] (warn_slowpath_null+0x34/0x4c) from [<c00a42c8>] (unlock_new_inode+0x20/0x3c)
[<c00a42c8>] (unlock_new_inode+0x20/0x3c) from [<c00a61b8>] (iget_failed+0x14/0x20)
[<c00a61b8>] (iget_failed+0x14/0x20) from [<c00f75cc>] (squashfs_fill_super+0x3c8/0x508)
[<c00f75cc>] (squashfs_fill_super+0x3c8/0x508) from [<c0095990>] (get_sb_bdev+0x110/0x16c)
[<c0095990>] (get_sb_bdev+0x110/0x16c) from [<c00f7164>] (squashfs_get_sb+0x18/0x20)
[<c00f7164>] (squashfs_get_sb+0x18/0x20) from [<c0095008>] (vfs_kern_mount+0x44/0xd8)
[<c0095008>] (vfs_kern_mount+0x44/0xd8) from [<c00950e0>] (do_kern_mount+0x34/0xe0)
[<c00950e0>] (do_kern_mount+0x34/0xe0) from [<c00a9084>] (do_mount+0x5d8/0x658)
[<c00a9084>] (do_mount+0x5d8/0x658) from [<c00a9330>] (sys_mount+0x84/0xc4)
[<c00a9330>] (sys_mount+0x84/0xc4) from [<c0008c60>] (mount_block_root+0xe4/0x20c)
[<c0008c60>] (mount_block_root+0xe4/0x20c) from [<c00090fc>] (prepare_namespace+0x160/0x1c0)
[<c00090fc>] (prepare_namespace+0x160/0x1c0) from [<c00089c8>] (kernel_init+0xd8/0x104)
[<c00089c8>] (kernel_init+0xd8/0x104) from [<c0033738>] (kernel_thread_exit+0x0/0x8)
---[ end trace c21b44698de8995c ]---
VFS: Cannot open root device "mtdblock5" or unknown-block(31,5)
Please append a correct "root=" boot option; here are the available partitions:
1f00 256 mtdblock0 (driver?)
1f01 128 mtdblock1 (driver?)
1f02 640 mtdblock2 (driver?)
1f03 5120 mtdblock3 (driver?)
1f04 5120 mtdblock4 (driver?)
1f05 40960 mtdblock5 (driver?)
1f06 40960 mtdblock6 (driver?)
1f07 167936 mtdblock7 (driver?)
1f08 1024 mtdblock8 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,5)
[<c0037750>] (unwind_backtrace+0x0/0xcc) from [<c02fdd40>] (panic+0x3c/0x114)
[<c02fdd40>] (panic+0x3c/0x114) from [<c0008d44>] (mount_block_root+0x1c8/0x20c)
[<c0008d44>] (mount_block_root+0x1c8/0x20c) from [<c00090fc>] (prepare_namespace+0x160/0x1c0)
[<c00090fc>] (prepare_namespace+0x160/0x1c0) from [<c00089c8>] (kernel_init+0xd8/0x104)
[<c00089c8>] (kernel_init+0xd8/0x104) from [<c0033738>] (kernel_thread_exit+0x0/0x8)
Eu tentei montar o sistema de arquivos na partição mtdblock6 e tudo funcionou como esperado, já que não há badblocks nessa parte da memória. Eu investiguei os arquivos de origem do mtd responsáveis pelo gerenciamento de blocos defeituosos, mas não consegui encontrar algo útil sobre como o kernel pula os blocos ruins.
Descobrimos que o problema é com o próprio squashfs. Não tem suporte para detecção de blocos ruins, conforme declarado aqui:
Portanto, a solução possível é usar outro sistema de arquivos ou usar o UBI para gerenciar os blocos defeituosos e continuar usando o squashfs.
Você tentou adicionar algo como 'rootdelay = 2' (ou mais, até 10 eu acredito) aos seus argumentos de inicialização? Pode dar ao flash um pouco de tempo extra para resolver as coisas antes que ele seja acessado pelo kernel.