Hmm, fsr does funky stuff, it could be the culprit here. It uses a special
call to flip the entent info between two inodes, maybe it has a reference
count problem.
Steve
> This looks suspicious (happened a few minutes ago). Should I try turning
> xfs_fsr off?
>
> Apr 2 23:00:00 page fsr[2746]: / startino=0
> Apr 2 23:00:05 page fsr[2755]: /attic startino=0
> Apr 2 23:00:05 page fsr[2756]: /boot startino=0
> Apr 2 23:00:05 page fsr[2757]: /data startino=0
> Apr 2 23:00:06 page fsr[2760]: /usr startino=0
> Apr 2 23:00:55 page kernel: kernel BUG at dcache.c:349!
> Apr 2 23:00:55 page kernel: invalid operand: 0000
> Apr 2 23:00:55 page kernel: CPU: 0
> Apr 2 23:00:55 page kernel: EIP: 0010:[prune_dcache+117/332]
> Apr 2 23:00:55 page kernel: EFLAGS: 00010292
> Apr 2 23:00:55 page kernel: eax: 0000001c ebx: c2c070e0 ecx: 00000000
> edx: 00000001
> Apr 2 23:00:55 page kernel: esi: c2c070c0 edi: c0c11a40 ebp: 0000009f
> esp: c12e7f98
> Apr 2 23:00:55 page kernel: ds: 0018 es: 0018 ss: 0018
> Apr 2 23:00:55 page kernel: Process kswapd (pid: 4, stackpage=c12e7000)
> Apr 2 23:00:55 page kernel: Stack: c02aff41 c02b0001 0000015d 00010f00 00000
> 020 00000004 00000000 c01426b1
> Apr 2 23:00:55 page kernel: 000001c2 c012b06b 00000006 00000004 00010
> f00 c02abdd1 c12e6239 0008e000
> Apr 2 23:00:55 page kernel: c012b0fb 00000004 00000000 c12f9fb0 c0105
> 000 00000031 c010752f 00000000
> Apr 2 23:00:55 page kernel: Call Trace: [shrink_dcache_memory+33/48] [do_try
> _to_free_pages+95/124] [kswapd+115/272] [empty_bad_page+0/4096] [kernel_threa
> d+35/48]
> Apr 2 23:00:56 page kernel:
> Apr 2 23:00:56 page kernel: Code: 0f 0b 83 c4 0c 8d 46 18 8b 53 f8 8b 48 04
> 89 4a 04 89 11 89
>
>
>
> cheers,
> Lennert
|