System is stable/7: 7.2-PRERELEASE r191214 i386 uni-processor.
NFS mount options: ro,noauto,nfsv3,tcp,intr,rdirplus,-r=32768,-w=32768
The panic occurred on client after losing and then restoring
connectivity with NFS server. There may have been parallel access to
NFS-mounted tree at the time of the accident.
Kernel messages just before the panic:
kernel: nfs server odyssey:/usr/ports: not responding
kernel: nfs send error 57 for server odyssey:/usr/ports
kgdb information:
#0 doadump () at pcpu.h:196
#1 0xc0555a33 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc0555c7f in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc064be63 in nfs_connect_unlock (rep=0x0) at
/usr/src/sys/nfsclient/nfs_socket.c:1819
#4 0xc064da24 in nfs_reconnect (rep=0xc40a0c80) at
/usr/src/sys/nfsclient/nfs_socket.c:581
#5 0xc064ff50 in nfs_request (vp=0xc4464450, mrest=0xc435a000,
procnum=3, td=0xc398cd20, cred=0xc420b800, mrp=0xdac06a04,
mdp=0xdac06a00, dposp=0xdac06a08)
at /usr/src/sys/nfsclient/nfs_socket.c:737
#6 0xc065d3f2 in nfs_lookup (ap=0xdac06a84) at
/usr/src/sys/nfsclient/nfs_vnops.c:922
#7 0xc0729cd6 in VOP_LOOKUP_APV (vop=0xc07a0fe0, a=0xdac06a84) at
vnode_if.c:99
#8 0xc05cad71 in lookup (ndp=0xdac06ba8) at vnode_if.h:57
#9 0xc05cbab8 in namei (ndp=0xdac06ba8) at
/usr/src/sys/kern/vfs_lookup.c:220
#10 0xc05db02d in kern_stat (td=0xc398cd20, path=0x2814d040 <Address
0x2814d040 out of bounds>, pathseg=UIO_USERSPACE, sbp=0xdac06c18)
at /usr/src/sys/kern/vfs_syscalls.c:2123
#11 0xc05db21f in stat (td=0xc398cd20, uap=0xdac06cfc) at
/usr/src/sys/kern/vfs_syscalls.c:2107
#12 0xc0712055 in syscall (frame=0xdac06d38) at
/usr/src/sys/i386/i386/trap.c:1090
#13 0xc06ff290 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:255
I am not sure why rep parameter shows up as NULL in nfs_connect_unlock
call. In frame 4:
(kgdb) p/x rep->r_nmp->nm_state
$2 = 0x10100000
I am keeping the core file.
--
Andriy Gapon
Hello, Experiencing some deadlock, I try to reenable my serial console on 7.2-RC1. (console="comconsole,vidconsole" in /boot/loader.conf and -Dh or -Dh -S115200 in /boot.config). /var/log/message show: 'sio0: type 16550A, console' and from the vga point of view, console output from kernel is slow as if echoed on a serial and rc output is going somewhere. At the other end of the serial, minicom show nothing and is 'offline'. A break at the minicom set my 7.2-RC1 in debugging (ddb) but 'continue' has no effect. The cable is working fine (serial console mode) with another box in 8.0-CURRENT. If I disable serial console and try minicom on 7.2-RC1, status is offline but any key is recieved at the other end and any key type at the other end is displayed fine. Does anyone encounter such a problem ? Thanks in advance henri
Any ideas, interest? I still have the core file. on 20/04/2009 13:04 Andriy Gapon said the following:> System is stable/7: 7.2-PRERELEASE r191214 i386 uni-processor. > > NFS mount options: ro,noauto,nfsv3,tcp,intr,rdirplus,-r=32768,-w=32768 > > The panic occurred on client after losing and then restoring > connectivity with NFS server. There may have been parallel access to > NFS-mounted tree at the time of the accident. > > Kernel messages just before the panic: > kernel: nfs server odyssey:/usr/ports: not responding > kernel: nfs send error 57 for server odyssey:/usr/ports > > kgdb information: > #0 doadump () at pcpu.h:196 > #1 0xc0555a33 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc0555c7f in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc064be63 in nfs_connect_unlock (rep=0x0) at > /usr/src/sys/nfsclient/nfs_socket.c:1819 > #4 0xc064da24 in nfs_reconnect (rep=0xc40a0c80) at > /usr/src/sys/nfsclient/nfs_socket.c:581 > #5 0xc064ff50 in nfs_request (vp=0xc4464450, mrest=0xc435a000, > procnum=3, td=0xc398cd20, cred=0xc420b800, mrp=0xdac06a04, > mdp=0xdac06a00, dposp=0xdac06a08) > at /usr/src/sys/nfsclient/nfs_socket.c:737 > #6 0xc065d3f2 in nfs_lookup (ap=0xdac06a84) at > /usr/src/sys/nfsclient/nfs_vnops.c:922 > #7 0xc0729cd6 in VOP_LOOKUP_APV (vop=0xc07a0fe0, a=0xdac06a84) at > vnode_if.c:99 > #8 0xc05cad71 in lookup (ndp=0xdac06ba8) at vnode_if.h:57 > #9 0xc05cbab8 in namei (ndp=0xdac06ba8) at > /usr/src/sys/kern/vfs_lookup.c:220 > #10 0xc05db02d in kern_stat (td=0xc398cd20, path=0x2814d040 <Address > 0x2814d040 out of bounds>, pathseg=UIO_USERSPACE, sbp=0xdac06c18) > at /usr/src/sys/kern/vfs_syscalls.c:2123 > #11 0xc05db21f in stat (td=0xc398cd20, uap=0xdac06cfc) at > /usr/src/sys/kern/vfs_syscalls.c:2107 > #12 0xc0712055 in syscall (frame=0xdac06d38) at > /usr/src/sys/i386/i386/trap.c:1090 > #13 0xc06ff290 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:255 > > I am not sure why rep parameter shows up as NULL in nfs_connect_unlock > call. In frame 4: > (kgdb) p/x rep->r_nmp->nm_state > $2 = 0x10100000 > > I am keeping the core file. >-- Andriy Gapon