Re: xfs_check problem

[Steve Lord <lord@xxxxxxx>]

Hi There,

I would direct this to the linux kernel mailing list, and reproduce, if
you can, with a very recent kernel. This looks like memory stress
caused by xfs_check is causing the vm to crash. This is not an XFS
bug, you could probably find different applications which would
do the same thing. xfs_check merely does a bunch of block I/O and
allocates a lot of user memory, it has no kernel component.

Steve

Ying-Hung Chen wrote:
> Hi there,
>
> we are currently having problem (kernel panic) running xfs_check on xfs
> partition >= 300G, while it doesn't happen EVERYTIME, but it happens
> about 50% of time (especially true when unexpected interruption
> happened, such as power failure and with bigger partition)
>
> I can run xfs_repair fine and xfs filesystem seems to be working fine. I
> know in the xfs_check man page, it mentioned about xfs_check may run out
> of meory in large filesystem, but i definitely does not expect kernel to
> panic.
>
> we are running kernel 2.6.14.2, xfsprogs at 2.6.13.
>
> anything I can try? or i shouldn't need to perform xfs_check everytime
> (or just run xfs_repair on startup?) thanks.
>
> I am attaching the panic log..
>
>  kernel BUG at <bad filename>:48363!
>  invalid operand: 0000 [#1]
>  Modules linked in: ds40xxhc dm_mod ftdi_sio usbserial uhci_hcd ehci_hcd
> i2c_i801 i2c_core
>  CPU:    0
>  EIP:    0060:[try_to_unmap+74/85]    Not tainted VLI
>  EIP:    0060:[<c0147555>]    Not tainted VLI
>  EFLAGS: 00010202   (2.6.14.2lm)
>  EIP is at try_to_unmap+0x4a/0x55
>  eax: 40008419   ebx: c1310000   ecx: 00000000   edx: 000000d0
>  esi: c1310000   edi: c15f1eac   ebp: c15f1f48   esp: c15f1e20
>  ds: 007b   es: 007b   ss: 0068
>  Process kswapd0 (pid: 175, threadinfo=c15f1000 task=c15e8a50)
>  Stack: c041ea80 c013eef0 00000001 00000000 c041ea80 00000000 00000000
> c131fff8
>         c131fff8 00000000 00000001 c0146d5a 00000001 00000001 00000000
> c11ee5a0
>         00000000 c15f1eb4 c041e42c 00000004 00000000 c013e0a5 00000202
> c013f7a7
>  Call Trace:
>   [shrink_list+367/1012] shrink_list+0x16f/0x3f4
>   [<c013eef0>] shrink_list+0x16f/0x3f4
>   [page_referenced_anon+65/104] page_referenced_anon+0x41/0x68
>   [<c0146d5a>] page_referenced_anon+0x41/0x68
>
>   [__pagevec_release+21/29] __pagevec_release+0x15/0x1d
>   [<c013e0a5>] __pagevec_release+0x15/0x1d
>   [refill_inactive_zone+823/865] refill_inactive_zone+0x337/0x361
>   [<c013f7a7>] refill_inactive_zone+0x337/0x361
>   [shrink_cache+220/608] shrink_cache+0xdc/0x260
>   [<c013f2ec>] shrink_cache+0xdc/0x260
>   [shrink_zone+170/204] shrink_zone+0xaa/0xcc
>   [<c013f87b>] shrink_zone+0xaa/0xcc
>   [balance_pgdat+592/959] balance_pgdat+0x250/0x3bf
>   [<c013fcee>] balance_pgdat+0x250/0x3bf
>   [kswapd+205/267] kswapd+0xcd/0x10b
>   [<c013ff2a>] kswapd+0xcd/0x10b
>   [autoremove_wake_function+0/55] autoremove_wake_function+0x0/0x37
>   [<c0128f4a>] autoremove_wake_function+0x0/0x37
>   [autoremove_wake_function+0/55] autoremove_wake_function+0x0/0x37
>   [<c0128f4a>] autoremove_wake_function+0x0/0x37
>   [kswapd+0/267] kswapd+0x0/0x10b
>   [<c013fe5d>] kswapd+0x0/0x10b
>   [kernel_thread_helper+5/11] kernel_thread_helper+0x5/0xb
>   [<c0101305>] kernel_thread_helper+0x5/0xb
>  Code: 8b 43 08 5b 85 c0 b8 00 00 00 00 0f 48 d0 89 d0 c3 89 d8 e8 d6 fd
> ff ff 89 c2 8b 43 08 5b 85 c0
> b8 00 00 00 00 0f 48 d0 89 d0 c3 <0f> 0b eb bc 0f 0b eb be 90 90 90 57
> 89 cf 56 89 d6 53 83 ec 10