From: Damien CLERMONTE <damien.clermonte@free.fr>
To: nfs@lists.sourceforge.net
Subject: nfs_put_unlinkdata oops with 2.6.13
Date: Thu, 08 Sep 2005 17:29:43 +0200 [thread overview]
Message-ID: <432058E7.7070202@free.fr> (raw)
Hi.
I'm having frequent oops in nfs_put_unlinkdata with linux 2.6.13 nfs
clients with a netapp nfs server.
The oops kills nfs completely, but the host continues to run.
Please CC me as I'm not on the list.
Thanks in advance.
Regards,
Damien
/proc/mounts options:
rw,nosuid,nodev,noexec,v3,rsize=32768,wsize=32768,hard,intr,tcp,lock
[...]
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
[...]
Unable to handle kernel paging request at virtual address 40e10020
c0237508
*pgd = 0
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c0237508>] Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010207 (2.6.13-grsec)
eax: 40e10020 ebx: f7bd3880 ecx: d4701180 edx: 40e10020
esi: 00000000 edi: f7bd3918 ebp: f7bd3898 esp: f744ef20
ds: 007b es: 007b ss: 0068
Stack: f7bd3898 c03904f4 f7bd3898 00000000 f7bd3898 c03900cc 00000003
f4ccd800
d31ca000 f7bd3914 d31ca000 c01a5478 00000000 c200e560 00000000
d31ca020
c0390190 00000296 f744e000 d31ca00c ffffffff ffffffff 00000001
00000000
Call Trace:
[<c03904f4>]
[<c03900cc>]
[<c01a5478>]
[<c0390190>]
[<c0191f50>]
[<c0191f50>]
[<c01a52e0>]
[<c01a90a4>]
[<c01a9000>]
[<c017bd75>]
Code: 83 d0 00 00 00 75 4c 8b 0d f4 d0 4e c0 ba f4 d0 4e c0 85 c9 74 1b
8d b6 00
00 00 00 8d bc 27 00 00 00 00 8b 02 39 d8 74 1e 89 c2 <8b> 00 85 c0 75
f2 8b 43
14 85 c0 75 08 89 d8 5b e9 f3 17 f8 ff
>>EIP; c0237508 <nfs_put_unlinkdata+38/70> <=====
>>eax; 40e10020 <phys_startup_32+40c95020/bff86000>
>>ebx; f7bd3880 <pg0+376b2880/3fadd400>
>>ecx; d4701180 <pg0+141e0180/3fadd400>
>>edx; 40e10020 <phys_startup_32+40c95020/bff86000>
>>edi; f7bd3918 <pg0+376b2918/3fadd400>
>>ebp; f7bd3898 <pg0+376b2898/3fadd400>
>>esp; f744ef20 <pg0+36f2df20/3fadd400>
Trace; c03904f4 <rpc_release_task+94/f0>
Trace; c03900cc <__rpc_execute+19c/230>
Trace; c01a5478 <worker_thread+198/240>
Trace; c0390190 <rpc_async_schedule+0/10>
Trace; c0191f50 <default_wake_function+0/10>
Trace; c0191f50 <default_wake_function+0/10>
Trace; c01a52e0 <worker_thread+0/240>
Trace; c01a90a4 <kthread+a4/b0>
Trace; c01a9000 <kthread+0/b0>
Trace; c017bd75 <kernel_thread_helper+5/10>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; c02374dd <nfs_put_unlinkdata+d/70>
00000000 <_EIP>:
Code; c02374dd <nfs_put_unlinkdata+d/70>
0: 83 d0 00 adc $0x0,%eax
Code; c02374e0 <nfs_put_unlinkdata+10/70>
3: 00 00 add %al,(%eax)
Code; c02374e2 <nfs_put_unlinkdata+12/70>
5: 75 4c jne 53 <_EIP+0x53>
Code; c02374e4 <nfs_put_unlinkdata+14/70>
7: 8b 0d f4 d0 4e c0 mov 0xc04ed0f4,%ecx
Code; c02374ea <nfs_put_unlinkdata+1a/70>
d: ba f4 d0 4e c0 mov $0xc04ed0f4,%edx
Code; c02374ef <nfs_put_unlinkdata+1f/70>
12: 85 c9 test %ecx,%ecx
Code; c02374f1 <nfs_put_unlinkdata+21/70>
14: 74 1b je 31 <_EIP+0x31>
Code; c02374f3 <nfs_put_unlinkdata+23/70>
16: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
Code; c02374f9 <nfs_put_unlinkdata+29/70>
1c: 8d bc 27 00 00 00 00 lea 0x0(%edi,1),%edi
Code; c0237500 <nfs_put_unlinkdata+30/70>
23: 8b 02 mov (%edx),%eax
Code; c0237502 <nfs_put_unlinkdata+32/70>
25: 39 d8 cmp %ebx,%eax
Code; c0237504 <nfs_put_unlinkdata+34/70>
27: 74 1e je 47 <_EIP+0x47>
Code; c0237506 <nfs_put_unlinkdata+36/70>
29: 89 c2 mov %eax,%edx
This decode from eip onwards should be reliable
Code; c0237508 <nfs_put_unlinkdata+38/70>
00000000 <_EIP>:
Code; c0237508 <nfs_put_unlinkdata+38/70> <=====
0: 8b 00 mov (%eax),%eax <=====
Code; c023750a <nfs_put_unlinkdata+3a/70>
2: 85 c0 test %eax,%eax
Code; c023750c <nfs_put_unlinkdata+3c/70>
4: 75 f2 jne fffffff8 <_EIP+0xfffffff8>
Code; c023750e <nfs_put_unlinkdata+3e/70>
6: 8b 43 14 mov 0x14(%ebx),%eax
Code; c0237511 <nfs_put_unlinkdata+41/70>
9: 85 c0 test %eax,%eax
Code; c0237513 <nfs_put_unlinkdata+43/70>
b: 75 08 jne 15 <_EIP+0x15>
Code; c0237515 <nfs_put_unlinkdata+45/70>
d: 89 d8 mov %ebx,%eax
Code; c0237517 <nfs_put_unlinkdata+47/70>
f: 5b pop %ebx
Code; c0237518 <nfs_put_unlinkdata+48/70>
10: e9 f3 17 f8 ff jmp fff81808 <_EIP+0xfff81808>
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
reply other threads:[~2005-09-08 15:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=432058E7.7070202@free.fr \
--to=damien.clermonte@free.fr \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox