Date: 18 Feb 2003 00:00:47 -0600 From: Craig Boston <craig@xfoil.gank.org> To: current@freebsd.org Subject: VFS panic (possibly NFS-locking related?) Message-ID: <1045548046.6639.14.camel@localhost>
next in thread | raw e-mail | index | archive | help
Hi everyone,
Just cvsuped from RELENG_5_0 to CURRENT and now the system panics when I
try to log in to gnome. It's a different process every time, but it
seems to be things that use file locks (my home dir is NFS mounted).
NFS access by programs that don't acquire locks seems to work okay.
Here's the panic and the backtrace: (more baseless speculation below all
the pasted junk)
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x50
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc0281a0c
stack pointer = 0x10:0xe12827b0
frame pointer = 0x10:0xe1282824
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 626 (mouse-properties-ca)
panic: from debugger
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc0233359 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:371
#2 0xc02335c3 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc014ef42 in db_panic () at /usr/src/sys/ddb/db_command.c:448
#4 0xc014eec2 in db_command (last_cmdp=0xc0405200, cmd_table=0x0,
aux_cmd_tablep=0xc03fc468, aux_cmd_tablep_end=0xc03fc46c)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc014efd6 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:470
#6 0xc0151d8a in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_trap.c:72
#7 0xc0388612 in kdb_trap (type=12, code=0, regs=0xe1282770)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc039a572 in trap_fatal (frame=0xe1282770, eva=0)
at /usr/src/sys/i386/i386/trap.c:839
#9 0xc039a282 in trap_pfault (frame=0xe1282770, usermode=0, eva=80)
at /usr/src/sys/i386/i386/trap.c:758
#10 0xc0399d70 in trap (frame=
{tf_fs = 24, tf_es = -517472240, tf_ds = 16, tf_edi = -517461588,
tf_esi = -517461548, tf_ebp = -517461980, tf_isp = -517462116, tf_ebx =
0, tf_edx = -997500336, tf_ecx = 0, tf_eax = 4, tf_trapno = 12, tf_err =
2, tf_eip = -1071113716, tf_cs = 8, tf_eflags = 66118, tf_esp =
-1003927580, tf_ss = -1042276352})
at /usr/src/sys/i386/i386/trap.c:445
#11 0xc0389f68 in calltrap () at {standard input}:96
#12 0xc029549a in vn_open_cred (ndp=0xe12829ac, flagp=0xe1282974,
cmode=0,
---Type <return> to continue, or q <return> to quit---
cred=0xc153ee80) at /usr/src/sys/kern/vfs_vnops.c:185
#13 0xc4286d75 in ?? ()
#14 0xc42938d8 in ?? ()
#15 0xc02141e1 in closef (fp=0xe1282bbc, td=0xc1e09e6c) at
vnode_if.h:1225
#16 0xc02138c6 in fdfree (td=0xc48b5a50)
at /usr/src/sys/kern/kern_descrip.c:1433
#17 0xc021a3f9 in exit1 (td=0xc48b5a50, rv=0)
at /usr/src/sys/kern/kern_exit.c:254
#18 0xc0219f9e in sys_exit () at /usr/src/sys/kern/kern_exit.c:116
#19 0xc039a8ca in syscall (frame=
{tf_fs = 47, tf_es = -65489, tf_ds = -1078001617, tf_edi = 0,
tf_esi = -1, tf_ebp = -1077937580, tf_isp = -517460620, tf_ebx =
677876540, tf_edx = 10, tf_ecx = 677876176, tf_eax = 1, tf_trapno = 0,
tf_err = 2, tf_eip = 677403871, tf_cs = 31, tf_eflags = 662, tf_esp =
-1077937608, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#20 0xc0389fbd in Xint0x80_syscall () at {standard input}:138
and some sleuthing:
(kgdb) up 12
#12 0xc029549a in vn_open_cred (ndp=0xe12829ac, flagp=0xe1282974,
cmode=0,
cred=0xc153ee80) at /usr/src/sys/kern/vfs_vnops.c:185
185 if ((error = namei(ndp)) != 0)
(kgdb) print ndp
$1 = (struct nameidata *) 0xe12829ac
(kgdb) print *ndp
$2 = {ni_dirp = 0xc42947e4 "/var/run/lock", ni_segflg = UIO_SYSSPACE,
ni_startdir = 0x10, ni_rootdir = 0x100100, ni_topdir = 0x100100,
ni_vp = 0xc48b5a50, ni_dvp = 0x0, ni_pathlen = 14,
ni_next = 0xc48b5a50 "ìI\213ÄP\201\213Ä", ni_loopcnt = 0, ni_cnd = {
cn_nameiop = 0, cn_flags = 68, cn_thread = 0xc48b5a50,
cn_cred = 0xc48edc80, cn_pnbuf = 0xc1e02000 "/var/run/lock",
cn_nameptr = 0xc4206238 " ¦CÀä:>Àä:>À", cn_namelen = -517461496,
cn_consume = -1071158062}}
(kgdb) up 3
#15 0xc02141e1 in closef (fp=0xe1282bbc, td=0xc1e09e6c) at
vnode_if.h:1225
1225 vnode_if.h: No such file or directory.
in vnode_if.h
(kgdb) up 1
#16 0xc02138c6 in fdfree (td=0xc48b5a50)
at /usr/src/sys/kern/kern_descrip.c:1433
1433 (void) closef(*fpp, td);
(kgdb) print fpp
$3 = (struct file **) 0xe1282bbc
(kgdb) print *fpp
$4 = (struct file *) 0x0
(kgdb) list 1430
1425 /*
1426 * We are the last reference to the structure, so we can
1427 * safely assume it will not change out from under us.
1428 */
1429 FILEDESC_UNLOCK(fdp);
1430 fpp = fdp->fd_ofiles;
1431 for (i = fdp->fd_lastfile; i-- >= 0; fpp++) {
1432 if (*fpp)
1433 (void) closef(*fpp, td);
1434 }
Hmm, it appears that this assumption may not be valid, as *fpp has
somehow become null between line 1432 and 1433.
I don't see it in the gdb backtrace, but when it broke into DDB I swear
I saw something about nfslck or something like that.
The panic is 100% reproducible. For now I'm falling back to 5.0 release
since it would be nice for the box to actually be usable ;) But it's a
1.8 Ghz so buildworlds aren't typically too bad. I'd be more than happy
to do some extra testing if it will help anyone track this one down.
Craig
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1045548046.6639.14.camel>