Hello, This is the 3rd time I get this kind of kernel panic. I thought I should report it here. OS: Centos 5.2 i386 CPU: dual Intel(R) Xeon(TM) CPU 2.40GHz Kernel: 2.6.18-92.1.22.el5PAE #1 SMP Mem: 4154240 EFLAGS: 00010206 (2.6.18-92.1.22.el5PAE #1) EIP is at call_start+0x4e/0x5b [sunrpc] eax: 34000045 ebx: f602b680 exc: f8d29344 edx: d86d9000 esi: e2235800 edi: 00000000 ebp: d3eb77c0 esp: d86d9f68 ds: 007b es: 007b ss: 0068 Process nfsv4-recall (pid: 22408, ti=d86d9000 task=d8091000 task,ti=d86d9000) Stack: f602b680 f602b6e8 f8d0fed9 f602b680 00000000 d86d9fa0 f8d0b94b ffffffff ffffffff e30c24f8 e30c252c fffffffb f8d9fb80 e2235800 f8daf4a0 e30c252c 00000000 d6dfe340 e30c24f8 f5e95abc f8d9b289 00000000 f8d9b29d f8da289a Call Trace: [<f8d0fed9>] __rpc_execute+0x7a/0x1f8 [sunrpc] [<f8d0b94b>] rpc_call_sync+0x6b/0x91 [sunrpc] [<f8d9fb80>] nfsd4_cb_recall+0xa9/0xf0 [nfsd] [<f8d9b289>] do_recall+0x0/0x19 [nfsd] [<f8d9b29d>] do_recall+0x14/0x19 [nfsd] [<c0436285>] kthread+0xc0/0xeb [<c04361c5>] kthread+0x0/0xeb [<c0405c3b>] kernel_thread_helper+0x7/0x10 ======================= Code: 43 1c ff 30 8b 46 30 ff 70 04 ff 76 18 0f b7 83 b0 00 00 00 50 68 cb 86 d1 f8 e8 9b b9 71 c7 83 c4 18 8b 43 1c ff 40 10 8b 46 20 <ff> 40 18 c7 43 3c 9c b0 d0 f8 5b 5e c3 f6 05 a8 e5 d2 f8 02 53 EIP: [<f8d0b08f>] call_start+0x4e/0x5b [sunrpc] SS:ESP 0068:d86d9f68 <0>Kernel panic - not syncing: Fatal exception I've also attached it just in case. Best regards, Giannis
Created attachment 337498 [details] panic trace
Today I updated to 5.3 and got another panic. kernel: 2.6.18-128.1.6.el5PAE I cannot, find a testcase to reproduce it on demand... Giannis
possible bug in 5.4 too -> http://bugs.centos.org/view.php?id=4229
[I'm the CentOS bug reporter] Try "echo 0 >/proc/sys/fs/leases-enable" on the server. After applying this horrible bodge my server (running 2.6.18-190.el5) has survived 52 days so far. J. Bruce Fields said on the NFSv4 mailing list: "Unfortunately that code has changed quite a bit since 2.6.18. I don't recall this specific bug, but I wouldn't be suprised if it's something we've since fixed. Looking through 'gitk v2.6.18.. fs/nfsd/nfs4callback.c fs/nfsd/nfs4state.c' for delegation/callback fixes might be one approach."
Hi, We are experiencing this issue on a CentOS 5.5 x86_64 server running 2.6.18-194.26.1.el5. It has happened twice in the last month. The hardware is a Dual Quad Core 12GB RAM serving both MySQL and NFS. I am not sure if applying Matt Bernstein's solution is a good idea. Is this bug scheduled to be fixed any time soon?
We're also seeing this on Red Hat EL 5.4 (2.6.18-164.6.1.el5). Virtual Machine (ESXi 4.1).
It help us if you could open a ticket with the RHEL support channel so they can help collect information for our developers. If you don't have an official RHEL subscription, the best place to raise this is on the linux-nfs email list with upstream developers. Thanks!
Is this still reproducible on current RHEL5 kernels?
No response in several months. Closing bug -- please reopen if you're able to reproduce on current RHEL5 kernels (5.9 or so).