Bug #1450
closed
Panic while using NFS
0%
Description
Moin,
one of my VMWare Virtual Machines running latest master from today
paniced. The panic is related to NFS. My $HOME is UDP mounted from a
Mac OS X NFS server. I opened a file when the machine died, no other
actions.
DragonFly hammer01 2.3.2-DEVELOPMENT DragonFly 2.3.2-DEVELOPMENT #2: Mon
Jun 8 06:16:11 CEST 2009
matthias@hammer01:/build/obj/build/src/sys/GENERIC i386
Unread portion of the kernel message buffer:
panic: assertion: tsiz <= nmp->nm_rsize in nfs_readrpc_bio
Trace beginning at frame 0xd9da2d00
panic(d9da2d24,4000,d9e30948,c2e2f5b4,d9da2d44) at panic+0x8c
panic(c0567357,c0588588,c054c001,0,0) at panic+0x8c
nfs_readrpc_bio(d9f47de8,c2e2f620) at nfs_readrpc_bio+0x6d
nfs_startio(d9f47de8,c2e2f620,0,d9f47de8,c2af1800) at nfs_startio+0x77
nfssvc_iod_writer(d9dadc00,0,0,0,0) at nfssvc_iod_writer+0x122
lwkt_exit() at lwkt_exit
(kgdb) bt
#0 dumpsys () at ./machine/thread.h:83
#1 0xc030d346 in boot (howto=260) at
/build/src/sys/kern/kern_shutdown.c:375
#2 0xc030d467 in panic (fmt=0xc056ab0e "from debugger") at
/build/src/sys/kern/kern_shutdown.c:801
#3 0xc016ba2d in db_panic (addr=-1068474624, have_addr=0, count=-1,
modif=0xd9da2bb0 "") at /build/src/sys/ddb/db_command.c:447
#4 0xc016c098 in db_command_loop () at
/build/src/sys/ddb/db_command.c:343
#5 0xc016e668 in db_trap (type=3, code=0) at
/build/src/sys/ddb/db_trap.c:71
#6 0xc050606c in kdb_trap (type=3, code=0, regs=0xd9da2cac) at
/build/src/sys/platform/pc32/i386/db_interface.c:152
#7 0xc0516f43 in trap (frame=0xd9da2cac) at
/build/src/sys/platform/pc32/i386/trap.c:797
#8 0xc0506da7 in calltrap () at
/build/src/sys/platform/pc32/i386/exception.s:785
#9 0xc0505f00 in Debugger (msg=0xc0581ee4 "panic") at
./cpu/cpufunc.h:73
#10 0xc030d45e in panic (fmt=0xc0567357 "assertion: %s in %s") at
/build/src/sys/kern/kern_shutdown.c:799
#11 0xc03d551a in nfs_readrpc_bio (vp=0xd9f47de8, bio=0xc2e2f620) at
/build/src/sys/vfs/nfs/nfs_bio.c:1606
#12 0xc03d6c67 in nfs_startio (vp=0x4, bio=0xc2e2f620, td=0x0) at
/build/src/sys/vfs/nfs/nfs_bio.c:1261
#13 0xc03ee7c4 in nfssvc_iod_writer (arg=0xd9dadc00) at
/build/src/sys/vfs/nfs/nfs_iod.c:190
#14 0xc0314f58 in lwkt_deschedule_self (td=Cannot access memory at
address 0x8
) at /build/src/sys/kern/lwkt_thread.c:259
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Core dump is available here: http://staatsfeind.org/~matthias/misc/core/
Cheers
Matthias
Updated by dillon over 15 years ago
:Moin,
:
:one of my VMWare Virtual Machines running latest master from today
:paniced. The panic is related to NFS. My $HOME is UDP mounted from a
:Mac OS X NFS server. I opened a file when the machine died, no other
:actions.
It looks like the client changed nm_rsize out from under itself.Did you by chance attempt to umount, remount, or mount -u
at some point? There are only a few places where nm_rsize can
be changed in the code.-Matt
Updated by matthias over 15 years ago
- Matthew Dillon wrote:
:Moin,
:
:one of my VMWare Virtual Machines running latest master from today
:paniced. The panic is related to NFS. My $HOME is UDP mounted from a
:Mac OS X NFS server. I opened a file when the machine died, no other
:actions.It looks like the client changed nm_rsize out from under itself.
Did you by chance attempt to umount, remount, or mount -u
at some point? There are only a few places where nm_rsize can
be changed in the code.
Yeah, I resumed the VM and remounted the NFS export to get my $HOME
again.
Cheers
Matthias
Updated by dillon over 15 years ago
:Yeah, I resumed the VM and remounted the NFS export to get my $HOME
:again.
:
:Cheers
:
: Matthias
All right, I committed a change to nfs to hopefully prevent these
fields from getting changed.You should not have to do any NFS remounts when resuming the VM.
DragonFly NFS clients should automatically reconnect.-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by