Messages in this thread | | | Date | Sat, 17 Jul 1999 00:01:48 +0100 (WEST) | From | "T.A. dos Santos" <> | Subject | Re: lockd problems |
| |
Hello. I had exactly the same problem, when i applied knfsd 1.4.4 patches to a stock 2.2.10 kernel. When people started working next day, lockd oopsed. I rebooted the machine to find it oopsing again in a couple of seconds. Got back imediately to kernel 2.2.7 with the same patches i had before. At least it doesnt oops on me, besides a problem i am evaluating now. Here comes a copy of the oops:
Unable to handle kernel NULL pointer dereference at virtual address 0000000c current->tss.cr3 = 00101000, %cr3 = 00101000 *pde = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[<c018e264>] EFLAGS: 00010202 eax: 00000004 ebx: c832bc80 ecx: 00000050 edx: c963c400 esi: fffffff4 edi: c0165220 ebp: 00000004 esp: c9081dc4 ds: 0018 es: 0018 ss: 0018 Process lockd (pid: 605, process nr: 53, stackpage=c9081000) Stack: c832bc80 c74d1d40 c963c400 00000004 0000000c 00000002 fffffeff ffffffff 00000015 c5b088e0 c0214d58 c5b088e0 c74d1d5c c018e5cb c018e5f8 c6884de0 c6884de0 c018df4e c5b088e0 c5b088e0 c0189b1a 00000001 c5b088e0 c9080000 Call Trace: [<c018e5cb>] [<c018e5f8>] [<c018df4e>] [<c0189b1a>] [<c0163234>] [<c 01627e5>] [<c0165220>] [<c0165200>] [<c0165220>] [<c0164d25>] [<c0164cdc>] [<c01850e8>] [<c018f5 c5>] [<c0165f63>] [<c0165fba>] [<c018f065>] [<c0163500>] [<c018f8ee>] [<c01636ee>] [<c0107aef>] Code: 66 ff 40 08 8b 4b 1c 8b 43 14 8b 50 18 a1 54 e1 20 c0 03 42
TA
On Fri, 16 Jul 1999, Steven N. Hirsch wrote:
> H.J., > > I'm having serious problems with NFS file locking. I'm running 2.2.10 > with Alan Cox's patchset ac10 applied. This has (AFAIK) all of your knfsd > fixes except for standalone lockd, which I originally added on top of his > (no conflicts whatever). > > Running a simple back-and-forth lock test between two processes on the > client sharing a file on the server, lockd crashes immediately: > > Jul 15 21:34:40 pii kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000c > Jul 15 21:34:40 pii kernel: current->tss.cr3 = 00101000, `r3 = 00101000 > Jul 15 21:34:40 pii kernel: *pde = 00000000 > Jul 15 21:34:40 pii kernel: Oops: 0002 > Jul 15 21:34:40 pii kernel: CPU: 1 > Jul 15 21:34:40 pii kernel: EIP: 0010:[<c017d18c>] > Jul 15 21:34:40 pii kernel: EFLAGS: 00013202 > Jul 15 21:34:40 pii kernel: eax: 00000004 ebx: cf6c03c0 ecx: cf6c0820 edx: 00000004 > Jul 15 21:34:40 pii kernel: esi: fffffff4 edi: c01516dc ebp: 00000002 esp: cf91fe0c > Jul 15 21:34:40 pii kernel: ds: 0018 es: 0018 ss: 0018 > Jul 15 21:34:40 pii kernel: Process lockd (pid: 203, process nr: 11, stackpage=cf91f000) > Jul 15 21:34:40 pii kernel: Stack: cf6c03c0 cf6c00a0 ce79fc00 00000004 0000000f cf91fe24 fffffeff ffffffff > Jul 15 21:34:40 pii kernel: cf757000 00000000 c0000000 cf91e000 cfcb75c0 400b9000 cfcb7340 c012e3b0 > Jul 15 21:34:40 pii kernel: 00000246 cfcb7240 cf91e000 00000001 cf9351d0 00000001 464c457f 00010101 > Jul 15 21:34:40 pii kernel: Call Trace: [<c012e3b0>] [<c0112111>] [<c014ed2f>] [<c01516dc>] [<c01516c4>] [<c01516dc>] [<c0151323>] > Jul 15 21:34:40 pii kernel: [<c011217e>] [<c0115154>] [<c0152213>] [<c0152264>] [<c017dee2>] [<c014fc8a>] [<c0107b8b>] > Jul 15 21:34:40 pii kernel: Code: 66 ff 40 08 8b 43 14 8b 4b 1c 8b 50 18 a1 80 e1 20 c0 03 42 > Copying default arch from ksymoops, bfd_arch=8 bfd_mach=0 > > >>EIP; c017d18c <rpcauth_releasecred+24/54> > Trace; c012e3b0 <do_execve+198/1d8> > Trace; c0112111 <reschedule_idle+1b9/1d4> > Trace; c014ed2f <nlmclnt_test+17/4c> > Trace; c01516dc <nlmsvc_callback_exit+40/54> > Trace; c01516c4 <nlmsvc_callback_exit+28/54> > Trace; c01516dc <nlmsvc_callback_exit+40/54> > Trace; c0151323 <nlmsvc_proc_share+37/cc> > Trace; c011217e <wake_up_process+52/68> > Trace; c0115154 <do_fork+7ac/8c8> > Trace; c0152213 <nlmsvc_decode_testargs+eb/19c> > Trace; c0152264 <nlmsvc_decode_testargs+13c/19c> > Trace; c017dee2 <svc_process+266/554> > Trace; c014fc8a <lockd+24a/294> > Trace; c0107b8b <kernel_thread+23/30> > Code; c017d18c <rpcauth_releasecred+24/54> 00000000 <_EIP>: > Code; c017d18c <rpcauth_releasecred+24/54> 0: 66 ff 40 08 incw 0x8(%eax) > Code; c017d190 <rpcauth_releasecred+28/54> 4: 8b 43 14 movl 0x14(%ebx),%eax > Code; c017d193 <rpcauth_releasecred+2b/54> 7: 8b 4b 1c movl 0x1c(%ebx),%ecx > Code; c017d196 <rpcauth_releasecred+2e/54> a: 8b 50 18 movl 0x18(%eax),%edx > Code; c017d199 <rpcauth_releasecred+31/54> d: a1 80 e1 20 c0 movl 0xc020e180,%eax > Code; c017d19e <rpcauth_releasecred+36/54> 12: 03 42 00 addl 0x0(%edx),%eax > > > I backed out the lockd patch and reverted to the knfsd utilities 1.4.2 > with the same results: > > Jul 16 16:39:34 pii kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000c > Jul 16 16:39:34 pii kernel: current->tss.cr3 = 00101000, `r3 = 00101000 > Jul 16 16:39:34 pii kernel: *pde = 00000000 > Jul 16 16:39:34 pii kernel: Oops: 0002 > Jul 16 16:39:34 pii kernel: CPU: 1 > Jul 16 16:39:34 pii kernel: EIP: 0010:[<c017d14c>] > Jul 16 16:39:34 pii kernel: EFLAGS: 00010202 > Jul 16 16:39:34 pii kernel: eax: 00000004 ebx: cf768140 ecx: cf71da40 edx: 00000004 > Jul 16 16:39:34 pii kernel: esi: fffffff4 edi: c015169c ebp: 00000002 esp: cf5d1e0c > Jul 16 16:39:34 pii kernel: ds: 0018 es: 0018 ss: 0018 > Jul 16 16:39:34 pii kernel: Process lockd (pid: 297, process nr: 26, stackpage=cf5d1000) > Jul 16 16:39:34 pii kernel: Stack: cf768140 cf7681e0 cda4ea00 00000004 0000000f cf5d1e24 fffffeff ffffffff > Jul 16 16:39:34 pii kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > Jul 16 16:39:34 pii kernel: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > Jul 16 16:39:34 pii kernel: Call Trace: [<c014ecff>] [<c015169c>] [<c0151684>] [<c015169c>] [<c01512e3>] [<c011217e>] [<c0115154>] > Jul 16 16:39:34 pii kernel: [<c01521d3>] [<c0152224>] [<c017dea2>] [<c014fc5a>] [<c0107b8b>] > Jul 16 16:39:34 pii kernel: Code: 66 ff 40 08 8b 43 14 8b 4b 1c 8b 50 18 a1 40 e0 20 c0 03 42 > Copying default arch from ksymoops, bfd_arch=8 bfd_mach=0 > > >>EIP; c017d14c <rpcauth_holdcred+38/54> > Trace; c014ecff <nlmclnt_async_call+9b/b4> > Trace; c015169c <nlmsvc_callback_exit+0/54> > Trace; c0151684 <nlmsvc_callback+70/88> > Trace; c015169c <nlmsvc_callback_exit+0/54> > Trace; c01512e3 <nlmsvc_proc_granted_msg+47/50> > Trace; c011217e <wake_up_process+52/68> > Trace; c0115154 <do_fork+7ac/8c8> > Trace; c01521d3 <nlmsvc_decode_testargs+ab/19c> > Trace; c0152224 <nlmsvc_decode_testargs+fc/19c> > Trace; c017dea2 <svc_process+226/554> > Trace; c014fc5a <lockd+21a/294> > Trace; c0107b8b <kernel_thread+23/30> > Code; c017d14c <rpcauth_holdcred+38/54> 00000000 <_EIP>: > Code; c017d14c <rpcauth_holdcred+38/54> 0: 66 ff 40 08 incw 0x8(%eax) > Code; c017d150 <rpcauth_holdcred+3c/54> 4: 8b 43 14 movl 0x14(%ebx),%eax > Code; c017d153 <rpcauth_holdcred+3f/54> 7: 8b 4b 1c movl 0x1c(%ebx),%ecx > Code; c017d156 <rpcauth_holdcred+42/54> a: 8b 50 18 movl 0x18(%eax),%edx > Code; c017d159 <rpcauth_holdcred+45/54> d: a1 40 e0 20 c0 movl 0xc020e040,%eax > Code; c017d15e <rpcauth_holdcred+4a/54> 12: 03 42 00 addl 0x0(%edx),%eax > > > Looks like the same underlying problem. > > I have attached the somewhat-simpleminded programs used to run the test. > It's 100% repeatable here between two Intel boxes (one SMP, one UP) > running the identical kernels and utilities in both cases. > > Let me know if you need more information? > > Steve > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |