Hmm, there is nothing in the changed code which should affect anything
but the write path in nfs. Have you tried a make clean and a complete
rebuild - I have been having problems myself in that area. However, there
have been a lot of changes since last friday.
This is pretty much a shot in the dark, but might make it go away.
Steve
>
> I just upgraded the kernel to CVS as of Mar 7 12:10 EST on our nfs
> server with a nice big xfs partition, and got this Oops from nfsd
> whenever a client tries to mount (filtered through ksymoops):
>
>
> ksymoops 2.3.4 on i686 2.4.2-XFS. Options used
> -v /usr/src/linux/vmlinux (specified)
> -K (specified)
> -l /proc/modules (default)
> -o /lib/modules/2.4.2-XFS (specified)
> -m /usr/src/linux/System.map (specified)
>
> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod
> Reading Oops report from the terminal
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> printing eip:
> c0169d64
> *pde = 00000000
> Oops: 0000
> CPU: 1
> EIP: 0010:[<c0169d64>]
> EFLAGS: 00010246
> eax: 00000000 ebx: c6efb980 ecx: 00000000 edx: c7c27f20
> esi: 00000000 edi: c02b901e ebp: c751b000 esp: c6e75efc
> ds: 0018 es: 0018 ss: 0018
> Process nfsd (pid: 584, stackpage=c6e75000)
> Stack: c6efb980 c6efb780 00000000 c751b000 c7484160 c7c27f20 c6e69f9c c6efb98
> 0
> c7554800 c6efb9a4 c751b000 c016dc2d c531bb04 c0167d49 c751b000 c6efb98
> 0
> 00000000 00000000 c6efb780 c751b000 c0301de0 c6e70014 c0167633 c751b00
> 0
> Call Trace: [<c016dc2d>] [<c0167d49>] [<c0167633>] [<c0290b28>] [<c01673da>]
> [<c
> 0107503>]
>
> Code: ac ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 3c
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> c0169d64
> *pde = 00000000
> Oops: 0000
> CPU: 1
> EIP: 0010:[<c0169d64>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010246
> eax: 00000000 ebx: c6efb980 ecx: 00000000 edx: c7c27f20
> esi: 00000000 edi: c02b901e ebp: c751b000 esp: c6e75efc
> ds: 0018 es: 0018 ss: 0018
> Process nfsd (pid: 584, stackpage=c6e75000)
> Stack: c6efb980 c6efb780 00000000 c751b000 c7484160 c7c27f20 c6e69f9c c6efb98
> 0
> c7554800 c6efb9a4 c751b000 c016dc2d c531bb04 c0167d49 c751b000 c6efb98
> 0
> 00000000 00000000 c6efb780 c751b000 c0301de0 c6e70014 c0167633 c751b00
> 0
> Call Trace: [<c016dc2d>] [<c0167d49>] [<c0167633>] [<c0290b28>] [<c01673da>]
> [<c
> 0107503>]
> Code: ac ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 75 3c
>
> >>EIP; c0169d64 <nfsd_lookup+94/52c> <=====
> Trace; c016dc2d <nfssvc_decode_diropargs+5d/d0>
> Trace; c0167d49 <nfsd_proc_lookup+7d/90>
> Trace; c0167633 <nfsd_dispatch+cb/168>
> Trace; c0290b28 <svc_process+2ac/544>
> Trace; c01673da <nfsd+1ca/358>
> Trace; c0107503 <kernel_thread+23/30>
> Code; c0169d64 <nfsd_lookup+94/52c>
> 00000000 <_EIP>:
> Code; c0169d64 <nfsd_lookup+94/52c> <=====
> 0: ac lods %ds:(%esi),%al <=====
> Code; c0169d65 <nfsd_lookup+95/52c>
> 1: ae scas %es:(%edi),%al
> Code; c0169d66 <nfsd_lookup+96/52c>
> 2: 75 08 jne c <_EIP+0xc> c0169d70 <nfsd_lookup+a
> 0/5
> 2c>
> Code; c0169d68 <nfsd_lookup+98/52c>
> 4: 84 c0 test %al,%al
> Code; c0169d6a <nfsd_lookup+9a/52c>
> 6: 75 f8 jne 0 <_EIP>
> Code; c0169d6c <nfsd_lookup+9c/52c>
> 8: 31 c0 xor %eax,%eax
> Code; c0169d6e <nfsd_lookup+9e/52c>
> a: eb 04 jmp 10 <_EIP+0x10> c0169d74 <nfsd_lookup
> +a4
> /52c>
> Code; c0169d70 <nfsd_lookup+a0/52c>
> c: 19 c0 sbb %eax,%eax
> Code; c0169d72 <nfsd_lookup+a2/52c>
> e: 0c 01 or $0x1,%al
> Code; c0169d74 <nfsd_lookup+a4/52c>
> 10: 85 c0 test %eax,%eax
> Code; c0169d76 <nfsd_lookup+a6/52c>
> 12: 75 3c jne 50 <_EIP+0x50> c0169db4 <nfsd_lookup
> +e4
> /52c>
>
> (And I really hope Evolution doesn't munge up that previous bit ;-)
>
> I just backed down to the previous working kernel, which was CVS from
> about last Friday, and everything is back to normal.
>
> Has anyone seen anything similar? I had upgraded in the hopes of fixing
> some (infrequent) I/O errors when accessing the nfs exported partition and
> benefitting from the nfs speed improvements...
>
> Thanks,
>
> - Vlad
>
>
|