xfs
[Top] [All Lists]

Re: nfs issues

To: dave <doood@xxxxxxxxxxxxx>
Subject: Re: nfs issues
From: Steve Lord <lord@xxxxxxx>
Date: Tue, 13 Mar 2001 09:32:41 -0600
Cc: linux-xfs@xxxxxxxxxxx
Comments: In-reply-to dave <doood@gruntwerk.net> message dated "Mon, 12 Mar 2001 16:51:17 -0800."
References: <200103101414.f2AEEI903763@jen.americas.sgi.com> <3AAD6F05.F221B0F2@gruntwerk.net>
Sender: owner-linux-xfs@xxxxxxxxxxx
It looks like your code base is quite out of sync with the current CVS tree,
well about 2 weeks anyway. The code in question changed on feb 27th and again
on march 5th. Let me know if this happens with current cvs code, and please
run the oops output through ksymoops - it is impossible to interpret the
data without symbol names attached.

Thanks

   Steve


> Steve Lord wrote:
> 
> > > Greetings,
> > >
> > >     I have been running the xfs filesystem for about 1mo now on a redhat
> > > 7.0 system. The box was installed using the SGI RedHat install iso, and
> > > its kernel re-compiled using the CVS tree.  Its /usr directory is
> > > exported to 4 other linux boxes over nfs v2 and v3. We are constanly
> > > having : nfs, cant get request slot errors between our workstations and
> > > the server. At times the kernel will dump a stack trace and print out:
> > > kernel bug 1339! I'm assuming it caused by the md driver, or the nfs
> > > load, or a combination of both. Any suggestions to a work around? Are
> > > there any new drivers I wouldn't get from CVS?
> > > Thanks in advance.
> > >
> > > Dave
> >
> > I have seen this error from my workstation accessing NFS servers which are
> > not running Linux, it may be a generic problem. This message comes from
> > this code:
> >
> >         if (clnt->cl_chatty && !(task->tk_flags & RPC_CALL_MAJORSEEN)) {
> >                 task->tk_flags |= RPC_CALL_MAJORSEEN;
> >                 if (req)
> >                         printk(KERN_NOTICE "%s: server %s not responding, s
> till trying\n",
> >                                 clnt->cl_protname, clnt->cl_server);
> > #ifdef RPC_DEBUG
> >                 else
> >                         printk(KERN_NOTICE "%s: task %d can't get a request
>  slot\n",
> >                                 clnt->cl_protname, task->tk_pid);
> > #endif
> >         }
> >
> > in an rpc timeout path, so this is a request timeout.
> >
> > I am not sure if this could be happening because or XFS or not. How recent 
> is
> > your kernel from cvs, there were changes this week (not complete until
> > yesterday) which help nfs performance considerably.
> >
> > Steve
> 
> Here's the exact kernel message:
> 
> kernel BUG at buffer.c:1399!
> invalid operand: 0000
> CPU:    0
> EIP:    0010:[<c01315b3>]
> EFLAGS: 00010292
> eax: 0000001d   ebx: c541de40   ecx: 00000000   edx: ffffffff
> esi: 000005a8   edi: c4eb2000   ebp: 00000000   esp: c6dfbd98
> ds: 0018   es: 0018   ss: 0018
> Process nfsd (pid: 553, stackpage=c6dfb000)
> Stack: c0297da5 c029801a 00000577 000005a8 000005a8 c4eb2000 00000a58 c541de4
> 0
>        c0122133 c11621d0 00000a58 c6dfbe00 c50f632c c50f6324 c50f6334 0000000
> 0
>        0002abb8 c11621d0 c6dfbe00 c012227b 00000048 c6e30c14 00000a58 0000000
> 0
> Call Trace: [<c0122133>] [<c012227b>] [<c01205e4>] [<c0142c5a>] [<c01ce2c4>] 
> [<c01d9985>]
> [<c01ce2c4>]
>        [<c0142d75>] [<c016a8fc>] [<c0168212>] [<c0167bf6>] [<c0285ef8>] [<c01
> 679c1>]
> [<c0107537>]
> 
> Code: 0f 0b 83 c4 0c 31 c0 66 8b 43 08 8b 73 28 8d 3c 28 39 6c 24
> 
> We have jsut rebuilt from CVS as of today so we'll see how it goes. Thanks ag
> ain.
> 
> Dave
> 



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