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 = 00000000
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
