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