xfs
[Top] [All Lists]

Re: NFS and xfsdump oops

To: Poul Petersen <petersp@xxxxxxxxxxxxx>
Subject: Re: NFS and xfsdump oops
From: Steve Lord <lord@xxxxxxx>
Date: Thu, 25 Oct 2001 11:38:13 -0500
Cc: "'Steve Lord'" <lord@xxxxxxx>, Matteo Centonza <matteo@xxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: Message from Poul Petersen <petersp@roguewave.com> of "Thu, 25 Oct 2001 09:37:22 PDT." <F888C30C3021D411B9DA00B0D0209BE801B4A984@cvo-exchange.roguewave.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
Yes, this is still on my list (somewhere), I just have too much going
on right now. There is some funky dcache stuff going on in the interface
which xfsdump uses. No workaround or anything as of yet, basically xfsdump
and nfs can stamp on each other and produce this result.

Steve

>       I thought I had seen this problem before, and indeed I have. Our NFS
> server has been running for months with no problems, but I recently added
> the xfs volume into amanda and:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> 00000000
> *pde = 00000000
> Oops: 0000
> CPU:    1
> EIP:    0010:[agp_frontend_cleanup+0/304]
> EIP:    0010:[<00000000>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010282
> eax: c038a360   ebx: da6a1aa0   ecx: e57910a0
> esi: d32bb940   edi: da6a1aa0   ebp: da6a1aa0
> ds: 0018   es: 0018   ss: 0018
> Process nfsd (pid: 693, stackpage=eb701000)
> Stack: c016fb94 e57910a0 d32bb940 0a0a67b7 00000020 c0170006 da6a1aa0
> f7c41080
>        ffffff8c 00000000 0a0a67b7 00000020 f5d4d204 eb56c800 c01703e1
> ec3a5200
>        0a0a67b7 00000020 00000000 00000001 000002b5 f5d4d214 11270000
> f5d4d204
> Call Trace: [nfsd_findparent+52/256] [find_fh_
> Call Trace: [<c016fb94>] [<c0170006>] [<c01703e1>] [<c0170a40>] [<c01766a1>]
> [<c016e221>] [<c02addd3>]
>        [<c016e039>] [<c0105546>] [<c016de40>]
> Code:  Bad EIP value.
> 
> >>EIP; 00000000 Before first symbol
> Trace; c016fb94 <nfsd_findparent+34/100>
> Trace; c0170006 <find_fh_dentry+246/390>
> Trace; c01703e1 <fh_verify+291/4d0>
> Trace; c0170a40 <nfsd_lookup+70/4a0>
> Trace; c01766a1 <nfsd3_proc_lookup+d1/e0>
> Trace; c016e221 <nfsd_dispatch+c1/160>
> Trace; c02addd3 <svc_process+353/4e0>
> Trace; c016e039 <nfsd+1f9/320>
> Trace; c0105546 <kernel_thread+26/30>
> Trace; c016de40 <nfsd+0/320>
> 
> > I have had a kernel pounding away with heavy nfs client access and
> > repeated level zero dumps ongoing in parallel. So far it is 
> > all working
> > just fine. I will leave it overnight and see if I cannot 
> > catch something.
> > 
> > Steve
> 
>       I noticed that the level 0 worked fine, but the Oops occurred the
> second night when amanda tried to run a level 1. I don't know if that has
> any bearing on the problem, but I've got a test server I am going to try and
> duplicate these results on. Our configuration is a Dell server (dual P-II
> 400) running RedHat 7.1 with 2.4.5 and XFS 1.0.1. 
> 
> Thanks for any insight,
> 
> 
> -poul



<Prev in Thread] Current Thread [Next in Thread>