Oops in rpciod when building procmail from an NFS client

Oops in rpciod when building procmail from an NFS client

[Yogesh Pahilwan]

[-- Attachment #1.1: Type: text/plain, Size: 3484 bytes --]

Hi Folks,

 

I am getting following oops while building procmail utility from the NFS
mounted share when build from the NFS client.

The NFS server oopses in rpciod during the "Benchmarking your system's
strstr () implementation" step.

 

I am using the following configurations for NFS client and server:

NFS client configuration: kernel version - 2.6.11-1.1369_FC4

NFS server configuration: kernel version - 2.4.19

Procmail version: v3.22

 

When I encountered the following oops I didn't kill the build process on
the client, and when I rebooted the server the build progressed a little
bit beyond where it was when the server crashed, and then the NFS server
oopsed again. I tried to kill the process again on the client (via
ctrl-c, ctrl-z), since it was unresponsive due to running off a mount to
the server while the server was unavailable; so instead I just killed
the console in the hopes that would kill the process tree including the
one stuck on the server mount. I rebooted the server again, and within a
minute or so it crashed yet again, seemingly spontaneously; and this
occurred again after another reboot. I checked the processes on the
client and found several stuck "_locktst /tmp/_locktest ./_locktest"
processes. These processes were in clusters of about 6 processes with
contiguous PIDs, and there were about the same number of these clusters
as the number of times I'd run the procmail make and oopsed the server.
Once I killed all these _locktst processes and rebooted the server
again, the oopsing stopped.

 

The oops:

 

Oops: 0000

CPU:    0

EIP:    0010:[<40313474>]    Not tainted

Using defaults from ksymoops -t elf32-i386 -a i386

EFLAGS: 00010246

eax: 00000000   ebx: 4e38dd20   ecx: 00000000   edx: 00000004

esi: 4e38c000   edi: 4e38dd20   ebp: 00000001   esp: 4fc41f20

ds: 0018   es: 0018   ss: 0018

Process rpciod (pid: 28706, stackpage=4fc41000)

Stack: 00000216 5408ac94 4e38c000 5a8a4720 4e38c000 5a8a4720 4031552d
4e38c000

       4e38dd20 40313967 4e38c000 4e38dd20 40313c70 00000000 00000000
4e38dd74

       4e38dd20 4fc40000 00000001 403165ca 4e38dd20 403aa000 4fc40000
410e09a0

Call Trace:    [<4031552d>] [<40313967>] [<40313c70>] [<403165ca>]
[<40113dac>]

  [<403168cd>] [<403170b1>] [<40317010>] [<4010757e>] [<40317010>]

Code: 8b 80 88 00 00 00 85 c0 74 39 c7 44 24 0c 00 00 00 00 8d 46

Error (pclose_local): Oops_decode pclose failed 0x7f00

Error (Oops_decode): no objdump lines read for /tmp/ksymoops.UQoI1x

 

>>EIP; 40313474 <__xprt_lock_write+54/f0>   <=====

 

>>ebx; 4e38dd20 <_end+df5ef5c/203d329c>

>>esi; 4e38c000 <_end+df5d23c/203d329c>

>>edi; 4e38dd20 <_end+df5ef5c/203d329c>

>>esp; 4fc41f20 <_end+f81315c/203d329c>

 

Trace; 4031552d <xprt_lock_write+1d/50>

Trace; 40313967 <xprt_reconnect+a7/3b0>

Trace; 40313c70 <xprt_reconn_status+0/80>

Trace; 403165ca <__rpc_execute+10a/2f0>

Trace; 40113dac <schedule+20c/350>

Trace; 403168cd <__rpc_schedule+8d/120>

Trace; 403170b1 <rpciod+a1/220>

Trace; 40317010 <rpciod+0/220>

Trace; 4010757e <kernel_thread+2e/40>

Trace; 40317010 <rpciod+0/220>

 

There is also a kernel panic that follows this.

 

Is there any patch available which fixes this nfs issue??? I would
appreciate if anyone tells me 

where should I get the patch (if available) to resolve this issue. 

 

 

Regards,

Yogesh

 

 

 


[-- Attachment #1.2: Type: text/html, Size: 13646 bytes --]

[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Oops in rpciod when building procmail from an NFS client

[Yogesh Pahilwan]

[-- Attachment #1.1: Type: text/plain, Size: 3484 bytes --]

Hi Folks,

 

I am getting following oops while building procmail utility from the NFS
mounted share when build from the NFS client.

The NFS server oopses in rpciod during the "Benchmarking your system's
strstr () implementation" step.

 

I am using the following configurations for NFS client and server:

NFS client configuration: kernel version - 2.6.11-1.1369_FC4

NFS server configuration: kernel version - 2.4.19

Procmail version: v3.22

 

When I encountered the following oops I didn't kill the build process on
the client, and when I rebooted the server the build progressed a little
bit beyond where it was when the server crashed, and then the NFS server
oopsed again. I tried to kill the process again on the client (via
ctrl-c, ctrl-z), since it was unresponsive due to running off a mount to
the server while the server was unavailable; so instead I just killed
the console in the hopes that would kill the process tree including the
one stuck on the server mount. I rebooted the server again, and within a
minute or so it crashed yet again, seemingly spontaneously; and this
occurred again after another reboot. I checked the processes on the
client and found several stuck "_locktst /tmp/_locktest ./_locktest"
processes. These processes were in clusters of about 6 processes with
contiguous PIDs, and there were about the same number of these clusters
as the number of times I'd run the procmail make and oopsed the server.
Once I killed all these _locktst processes and rebooted the server
again, the oopsing stopped.

 

The oops:

 

Oops: 0000

CPU:    0

EIP:    0010:[<40313474>]    Not tainted

Using defaults from ksymoops -t elf32-i386 -a i386

EFLAGS: 00010246

eax: 00000000   ebx: 4e38dd20   ecx: 00000000   edx: 00000004

esi: 4e38c000   edi: 4e38dd20   ebp: 00000001   esp: 4fc41f20

ds: 0018   es: 0018   ss: 0018

Process rpciod (pid: 28706, stackpage=4fc41000)

Stack: 00000216 5408ac94 4e38c000 5a8a4720 4e38c000 5a8a4720 4031552d
4e38c000

       4e38dd20 40313967 4e38c000 4e38dd20 40313c70 00000000 00000000
4e38dd74

       4e38dd20 4fc40000 00000001 403165ca 4e38dd20 403aa000 4fc40000
410e09a0

Call Trace:    [<4031552d>] [<40313967>] [<40313c70>] [<403165ca>]
[<40113dac>]

  [<403168cd>] [<403170b1>] [<40317010>] [<4010757e>] [<40317010>]

Code: 8b 80 88 00 00 00 85 c0 74 39 c7 44 24 0c 00 00 00 00 8d 46

Error (pclose_local): Oops_decode pclose failed 0x7f00

Error (Oops_decode): no objdump lines read for /tmp/ksymoops.UQoI1x

 

>>EIP; 40313474 <__xprt_lock_write+54/f0>   <=====

 

>>ebx; 4e38dd20 <_end+df5ef5c/203d329c>

>>esi; 4e38c000 <_end+df5d23c/203d329c>

>>edi; 4e38dd20 <_end+df5ef5c/203d329c>

>>esp; 4fc41f20 <_end+f81315c/203d329c>

 

Trace; 4031552d <xprt_lock_write+1d/50>

Trace; 40313967 <xprt_reconnect+a7/3b0>

Trace; 40313c70 <xprt_reconn_status+0/80>

Trace; 403165ca <__rpc_execute+10a/2f0>

Trace; 40113dac <schedule+20c/350>

Trace; 403168cd <__rpc_schedule+8d/120>

Trace; 403170b1 <rpciod+a1/220>

Trace; 40317010 <rpciod+0/220>

Trace; 4010757e <kernel_thread+2e/40>

Trace; 40317010 <rpciod+0/220>

 

There is also a kernel panic that follows this.

 

Is there any patch available which fixes this nfs issue??? I would
appreciate if anyone tells me 

where should I get the patch (if available) to resolve this issue. 

 

 

Regards,

Yogesh

 

 

 


[-- Attachment #1.2: Type: text/html, Size: 13625 bytes --]

[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Oops in rpciod when building procmail from an NFS client

[Jeff Layton]

On Wed, 14 Nov 2007 11:59:15 +0530
"Yogesh Pahilwan" <Yogesh.Pahilwan@symphonysv.com> wrote:

> NFS client configuration: kernel version - 2.6.11-1.1369_FC4

The oops you posted doesn't look familiar to me, but this kernel is
truly ancient. Fedora Core 4 is well past its end of life. I'd suggest
updating to Fedora 7 or 8 and seeing if your problem is still
reproducible.

-- 
Jeff Layton <jlayton@redhat.com>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Oops in rpciod when building procmail from an NFS client

[Neil Brown]

On Wednesday November 14, Yogesh.Pahilwan@symphonysv.com wrote:
> Hi Folks,
> 
>  
> 
> I am getting following oops while building procmail utility from the NFS
> mounted share when build from the NFS client.
> 
> The NFS server oopses in rpciod during the "Benchmarking your system's
> strstr () implementation" step.
> 
>  
> 
> I am using the following configurations for NFS client and server:
> 
> NFS client configuration: kernel version - 2.6.11-1.1369_FC4

This is a very old kernel.  It is very possible that there is a patch
since then, but it is also possible that it was so long ago that
no-one has a clear memory of it and no-one feels like hunting it down
for you.

I recommend upgrading to a more recent kernel - 2.6.20 at least, and
if the problem persists, report again.

Thanks,
NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs