[Yaffs] Kernel panic in clear_inode when using yaffs as rootfs

[Charles Manning]

On Wednesday 09 November 2005 17:06, Andre Renaud wrote:
> I'm using yaffs as the root filesystem for a unit, and it is
> experiencing repeatible crashes - always in the same place
> (fs/inode.c:252, clear_inode).
>
> This is in Linux 2.6.14, with the latest yaffs from CVS (although not
> the latest MTD, just the MTD that 2.6.14 shipped with). Using yaffs2 in
> yaffs1 compatibility mode (512byte NAND).
>
> I've attached the BUG output. Anyone have any ideas? The line that the
> bug reports to is:
> if (inode->i_data.nrpages)
> 	BUG();
> so inode->i_data.nrpages should be 0 when clear_inode is called - but it
> isn't for some reason.

Curious.

Is this code new/different in 2.6.14 compared with the last kernel tree you 
used?

What is different when being used as rootfs?

Is it 100% reproducable?

-- CHarles

>
> As far as I can tell this only happens when I'm using it as the rootfs.
>
> Thanks,
> Andre
>
> kernel BUG at fs/inode.c:252!7473 characters
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000000 pgd = c54f0000
> [00000000] *pgd=a54bd031, *pte=00000000, *ppte=00000000
> Internal error: Oops: 817 [#1]
> Modules linked in:
> CPU: 0
> PC is at __bug+0x40/0x54
> LR is at 0x1
> pc : [<c005a61c>]    lr : [<00000001>]    Not tainted
> sp : c541bec4  ip : 60000093  fp : c541bed4
> r10: 00061050  r9 : c541a000  r8 : c541bf44
> r7 : c550bec0  r6 : c550bec0  r5 : c592e074  r4 : 00000000
> r3 : 00000000  r2 : 00000000  r1 : 00001b60  r0 : 00000001
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
> Control: 397F  Table: A54F0000  DAC: 00000015
> Process vi (pid: 914, stack limit = 0xc541a194)
> Stack: (0xc541bec4 to 0xc541c000)
> bec0:          c550bec0 c541bee8 c541bed8 c00c2a54 c005a5e8 c05b0000
> c541bf04
> bee0: c541beec c010e0a4 c00c2a0c c550bec0 c010e034 c54aabb8 c541bf1c
> c541bf08
> bf00: c00c3908 c010e040 c550bec0 c54a9000 c541bf2c c541bf20 c00c3aec
> c00c3880
> bf20: c541bf40 c541bf30 c00c3b8c c00c3adc 00000000 c541bfa4 c541bf44
> c00b949c
> bf40: c00c3b04 c54aac40 c04741e0 74372a07 00000009 c54a9014 00000010
> 00000000
> bf60: 00000000 c541bf70 00000000 c00a88dc 00000005 c5faad60 c0468580
> c541bfa4
> bf80: c541bf8c 00063610 000635d8 00062998 0000000a c0054e84 00000000
> c541bfa8
> bfa0: c0054d00 c00b9374 00063610 c02a8bcc 000636a0 00000048 00000000
> 00000041
> bfc0: 00063610 000635d8 00062998 00000000 00000000 00000000 00061050
> 00000000
> bfe0: 000607ac bee8cb9c 000226fc 40117d54 20000010 000636a0 00000000
> 00000000
> Backtrace:
>
> [<c005a5dc>] (__bug+0x0/0x54) from [<c00c2a54>] (clear_inode+0x54/0xc8)
>  r4 = C550BEC0
> [<c00c2a00>] (clear_inode+0x0/0xc8) from [<c010e0a4>]
> (yaffs_delete_inode+0x70/0x84)
>  r4 = C05B0000
>
> [<c010e034>] (yaffs_delete_inode+0x0/0x84) from [<c00c3908>]
> (generic_delete_inode+0x94/0x108)
>  r6 = C54AABB8  r5 = C010E034  r4 = C550BEC0
>
> [<c00c3874>] (generic_delete_inode+0x0/0x108) from [<c00c3aec>]
> (generic_drop_inode+0x1c/0x28)
>  r5 = C54A9000  r4 = C550BEC0
>
> [<c00c3ad0>] (generic_drop_inode+0x0/0x28) from [<c00c3b8c>]
> (iput+0x94/0xa8)
> [<c00c3af8>] (iput+0x0/0xa8) from [<c00b949c>] (sys_unlink+0x134/0x180)
>
>  r4 = 00000000
> [<c00b9368>] (sys_unlink+0x0/0x180) from [<c0054d00>]
> (ret_fast_syscall+0x0/0x2c)
>  r8 = C0054E84  r7 = 0000000A  r6 = 00062998  r5 = 000635D8
>
>  r4 = 00063610
> Code: 1b004110 e59f0014 eb00410e e3a03000 (e5833000)
>  Segmentation fault
>
> _______________________________________________
> yaffs mailing list
> yaffs at stoneboat.aleph1.co.uk
> http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs