On Sat, Feb 25, 2006 at 05:42:19PM -0500, Kris Kennaway wrote: > On Sat, Feb 25, 2006 at 09:17:30AM -0500, Kris Kennaway wrote: > > Panic on 6.1-PRERELEASE (package build machine): > > > > db> wh > > Tracing pid 85657 tid 100133 td 0xc2612600 > > kdb_enter(c06cabdd,c07250c0,c06cc327,cdca4cac,100) at kdb_enter+0x30 > > panic(c06cc327,2,c06cc3bf,267,2814d4e8) at panic+0xd5 > > sched_userret(c2612600,c04e290d,c0724dc0,1,2814d4e8) at sched_userret+0x21 > > userret(c2612600,cdca4d38,63,100,1010000) at userret+0xd8 > > ast(cdca4d38) at ast+0x556 > > doreti_ast() at doreti_ast+0x17 > > > > Core available. > > The only other process active was: > > 85837 c239d000 0 85836 73099 0004000 [LOCK vnode interlock c23cae40] > pkg_add > > which is holding a lock: > > db> show lockedvnods > Locked vnodes > > 0xc2d09000: tag devfs, type VDIR > usecount 2, writecount 0, refcount 2 mountedhere 0 > flags (VV_ROOT) > lock type devfs: EXCL (count 1) by thread 0xc1f1fc00 (pid 85837) > db> wh 85837 > Tracing pid 85837 tid 100077 td 0xc1f1fc00 > sched_switch(c1f1fc00,0,1,118,8948ac5f) at sched_switch+0x190 > mi_switch(1,0,c06cdf0d,253,c07293a8) at mi_switch+0x2e6 > turnstile_wait(c3192d3c,c2612600,c06c9e64,225,c2612602) at > turnstile_wait+0x3b6 > _mtx_lock_sleep(c3192d3c,c1f1fc00,0,c06d264c,797) at _mtx_lock_sleep+0x137 > _mtx_lock_flags(c3192d3c,0,c06d264c,797,2) at _mtx_lock_flags+0x9b > vget(c3192cc0,2,c1f1fc00,c23e8405,c2a2ce60) at vget+0x47 > devfs_allocv(c2a2ce00,c1f5c400,cc9e8bd8,c1f1fc00,cc9e88a8) at > devfs_allocv+0x43 > devfs_lookupx(cc9e8998,c06c3419,23f,c06f89c0,cc9e8998) at devfs_lookupx+0x569 > devfs_lookup(cc9e8998,cc9e8998,c2d09000,c2d09000,0) at devfs_lookup+0x3e > VOP_LOOKUP_APV(c06f89c0,cc9e8998,cc9e8984,c1f1fc00,0) at VOP_LOOKUP_APV+0xb4 > lookup(cc9e8bc4,0,c06d1dd1,b6,1b2) at lookup+0x488 > namei(cc9e8bc4,c33bf660,c1f1fc00,cc9e8a58,c05529ed) at namei+0x468 > vn_open_cred(cc9e8bc4,cc9e8cc4,0,c2c5e700,3) at vn_open_cred+0x2d8 > vn_open(cc9e8bc4,cc9e8cc4,0,3,0) at vn_open+0x33 > kern_open(c1f1fc00,2827b19f,0,1,0) at kern_open+0xc8 > open(c1f1fc00,cc9e8d04,c,41d,3) at open+0x36 > syscall(3b,3b,3b,bfbfd6f0,bfbfd705) at syscall+0x2c0 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (5, FreeBSD ELF32, open), eip = 0x28264eab, esp = 0xbfbfb7bc, ebp > = 0xbfbfb8b8 --- > db> > > Interestingly, almost the same trace appeared in an amd64 7.0 panic > overnight, on a machine with DEBUG_VFS_LOCKS enabled: > > VNASSERT failed > 0xffffff03067c13b0: tag none, type VBAD > usecount 0, writecount 0, refcount 1 mountedhere 0 > flags (VI_DOOMED) > VI_LOCKed > panic: No vop_lock(0xffffff03067c13b0, 0xffffffffae46c330) > cpuid = 3 > KDB: enter: panic > [thread pid 5883 tid 100224 ] > Stopped at kdb_enter+0x31: leave > db> wh > Tracing pid 5883 tid 100224 td 0xffffff0310aa97e0 > kdb_enter() at kdb_enter+0x31 > panic() at panic+0x1e6 > VOP_LOCK_APV() at VOP_LOCK_APV+0xb4 > vn_lock() at vn_lock+0xc8 > vget() at vget+0xf0 > devfs_allocv() at devfs_allocv+0x60 > devfs_lookupx() at devfs_lookupx+0x53b > devfs_lookup() at devfs_lookup+0x43 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xbb > lookup() at lookup+0x4b5 > namei() at namei+0x3fb > vn_open_cred() at vn_open_cred+0x95 > vn_open() at vn_open+0x17 > kern_open() at kern_open+0xe6 > open() at open+0x28 > syscall() at syscall+0x350 > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (5, FreeBSD ELF64, open), rip = 0x800979dec, rsp = > 0x7fffffffc4e8, rbp = 0x5c2dd0 ---
It's indeed the same panic. From the i386 core:
(kgdb) inspect *vp
$2 = {v_type = VBAD, v_tag = 0xc06c2773 "none", v_op = 0x0, v_data = 0x0,
v_mount = 0x0, v_nmntvnodes = {
i.e. if DEBUG_VFS_LOCKS were enabled, this would have triggered the
same assertion as on amd64, from the null v_op:
VNASSERT failed
0xffffff03067c13b0: tag none, type VBAD
usecount 0, writecount 0, refcount 1 mountedhere 0
flags (VI_DOOMED)
VI_LOCKed
panic: No vop_lock(0xffffff03067c13b0, 0xffffffffae46c330)
I guess someone was beaming bogon rays along a line that happened to
intersect these two separated machines..I wonder what else is along
that line of sight :-)
Kris
pgpDsEOF5GLIm.pgp
Description: PGP signature
