Hi Steve,
I have try the new kernel 2.6.16.11 this morning, xfs_check doesn't
cause it to crash anymore but it does leave some ugly looking message
"Trying to fix it up, but a reboot is needed", i'll try to do more
testing and see what happens.
Anyhow, I just want to know if there is any event that we want to run
xfs_check instead of xfs_repair directly (since we usually want check
the filesystem AND fix them if there is any errors)
Thanks,
-Ying
Steve Lord wrote:
> 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
>>
|