Panic while using NFS
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
DragonFly hammer01 2.3.2-DEVELOPMENT DragonFly 2.3.2-DEVELOPMENT #2: Mon
Jun 8 06:16:11 CEST 2009
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
#0 dumpsys () at ./machine/thread.h:83
#1 0xc030d346 in boot (howto=260) at
#2 0xc030d467 in panic (fmt=0xc056ab0e "from debugger") at
#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
#5 0xc016e668 in db_trap (type=3, code=0) at
#6 0xc050606c in kdb_trap (type=3, code=0, regs=0xd9da2cac) at
#7 0xc0516f43 in trap (frame=0xd9da2cac) at
#8 0xc0506da7 in calltrap () at
#9 0xc0505f00 in Debugger (msg=0xc0581ee4 "panic") at
#10 0xc030d45e in panic (fmt=0xc0567357 "assertion: %s in %s") at
#11 0xc03d551a in nfs_readrpc_bio (vp=0xd9f47de8, bio=0xc2e2f620) at
#12 0xc03d6c67 in nfs_startio (vp=0x4, bio=0xc2e2f620, td=0x0) at
#13 0xc03ee7c4 in nfssvc_iod_writer (arg=0xd9dadc00) at
#14 0xc0314f58 in lwkt_deschedule_self (td=Cannot access memory at
) 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/
#1 Updated by dillon over 8 years ago
: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
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.
#2 Updated by matthias over 8 years ago
* Matthew Dillon wrote:
> :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
> 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
#3 Updated by dillon over 8 years ago
:Yeah, I resumed the VM and remounted the NFS export to get my $HOME
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.