I got the word about the changes to vfs_subr.c vfs_bio.c fixing
the hang at shutdown for yesterday's -CURRENT fairly late in the
day yesterday, and since the problem didn't seem (as far as I could
tell) to affect normal operation, I figured I'd just pick up the
change at the following update (which would be this morning).
However, once I started the make -j8 buildworld on this SMP machine
(this morning), I got a panic. Here's a cut-and-paste from the
serial console:
Recovering vi editor sessions:.
Initial rc.i386 initialization:.
Configuring syscons: blanktime.
Additional ABI support:.
Local package initiCalization:reating DISK md10
md10: invalid primary partition table: no magic
md10: invalid primary partition table: no magic
[1] 232 Floating point exception (core dumped)
Jul 7 05:41:21 freebeast kernel: pid 232 (newfs), uid 0: exited on signal 8 (core
dumped)
apache cvsupd
.
Additional TCP options:.
Starting background filesystem checks
Sun Jul 7 05:41:23 PDT 2002
FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0)
login: panic: lockmgr: locking against myself
cpuid = 0; lapic.id =
Debugger(panic)
Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
db tr
Debugger(c030085a) at Debugger+0x46
panic(c02fe680,7,0,ce6811c0,2010022) at panic+0xd6
lockmgr(ce6811c0,2010022,c0347060,c1584cc0) at lockmgr+0x36b
BUF_TIMELOCK(ce681114,22,c03085c1,0,0) at BUF_TIMELOCK+0x62
getblk(c421a200,e44030,0,2000,0) at getblk+0x97
breadn(c421a200,e44030,0,2000,0) at breadn+0x2f
bread(c421a200,e44030,0,2000,0,d69d7920) at bread+0x20
ffs_blkfree(c41ad800,c421a200,723f8e,0,400) at ffs_blkfree+0x2ba
ffs_truncate(c469a300,0,0,0,0) at ffs_truncate+0xff5
ufs_inactive(d69d7bac,d69d7bc4,c01eecd1,d69d7bac,c03312c0) at ufs_inactive+0x8e
ufs_vnoperate(d69d7bac) at ufs_vnoperate+0x13
vrele(c469a300,ce76ce60,c46a5258,d69d7bec,c029d4fd) at vrele+0xb1
vm_object_vndeallocate(c46a5258,ce76ce60,ce76ce60,d69d7bfc,c01ee0c6) at
vm_object_vndeallocate+0x6e
vm_object_deallocate(c46a5258,c09b5334,d69d7c14,c01e3673,ce76ce60) at
vm_object_deallocate+0x35
brelvp(ce76ce60) at brelvp+0xd2
vfs_vmio_release(ce76ce60) at vfs_vmio_release+0x14f
getnewbuf(0,0,2000,4000,200010a4) at getnewbuf+0x15e
geteblk(2000,0,c02fe5e2,23b,ce681114) at geteblk+0x23
bwrite(ce681114,d69d7cb0,c0188a5d,ce681114,2710) at bwrite+0x126
bawrite(ce681114) at bawrite+0x14
spec_fsync(d69d7ce0,d69d7d1c,c01ee24a,d69d7ce0,3d2837b7) at spec_fsync+0xc9
spec_vnoperate(d69d7ce0,3d2837b7,c41ba200,c0331380,c41b6e00) at spec_vnoperate+0x13
sched_sync(0,d69d7d48,c1584cc0,c01ee154,0) at sched_sync+0xf6
fork_exit(c01ee154,0,d69d7d48) at fork_exit+0xa8
fork_trampoline() at fork_trampoline+0x37
db show pcpu 0
cpuid= 0
curthread= 0xc1584cc0: pid 7 syncer
curpcb = 0xd69d7da0
fpcurthread = none
idlethread = 0xc1583d80: pid 12 idle: cpu0
currentldt = 0x28
spin locks held:
db show pcpu 1
cpuid= 1
curthread= 0xc1583e40: pid 11 idle: cpu1
curpcb = 0xd699eda0
fpcurthread = none
idlethread = 0xc1583e40: pid 11 idle: cpu1
currentldt = 0x28
spin locks held:
db show locks
exclusive sleep mutex Giant r = 1 (0xc0340d00) locked @
/usr/src/sys/vm/vm_object.c:1721
db
I'm going ahead and sending this in because it seems fairly different
from the traceback that was reported for yesterday's hang, so there
might be some other problem that is shows.
I will go ahead and reboot, and upgrade the kernel first, then see how
a make buildworld goes.
Cheers,
david
--
David H. Wolfskill [EMAIL PROTECTED]
Trying to support or use Microsoft products makes about as much sense
as painting the outside of a house with watercolors.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
