From skynyrd@opus.cts.cwu.edu  Tue Oct 13 15:23:34 1998
Received: from opus.cts.cwu.edu (opus.cts.cwu.edu [198.104.92.71])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA08818
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 13 Oct 1998 15:23:33 -0700 (PDT)
          (envelope-from skynyrd@opus.cts.cwu.edu)
Received: (from skynyrd@localhost)
	by opus.cts.cwu.edu (8.9.1/8.9.1) id PAA01780;
	Tue, 13 Oct 1998 15:23:18 -0700 (PDT)
Message-Id: <199810132223.PAA01780@opus.cts.cwu.edu>
Date: Tue, 13 Oct 1998 15:23:18 -0700 (PDT)
From: skynyrd@opus.cts.cwu.edu
Reply-To: skynyrd@opus.cts.cwu.edu
To: FreeBSD-gnats-submit@freebsd.org
Subject: SMP panic via reboot(8): "panic: rslock: ..."
X-Send-Pr-Version: 3.2

>Number:         8309
>Category:       kern
>Synopsis:       SMP panic via reboot(8): "panic: rslock: ..."
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Oct 13 15:30:00 PDT 1998
>Closed-Date:    Wed Oct 14 13:43:57 PDT 1998
>Last-Modified:  Wed Oct 14 13:48:56 PDT 1998
>Originator:     Chris Timmons
>Release:        FreeBSD 3.0-BETA (Oct 13, 1998 ~1700 UTC)
>Organization:
Central Washington University
>Environment:

	3.0-BETA SMP kernel, 4xfxp ethernet, 1xAHA-3940AUW,
                             5x4GB disk across a & b channels.

	Tyan Tiger dual PII-266 motherboard

>Description:

panic: rslock: cpu: 0, addr: 0xf930b208, lock: 0x00000001
mp_lock = 00000001; cpuid = 0; lapic.id = 00000000
panic: from debugger
mp_lock = 00000002; cpuid = 0; lapic.id = 00000000
boot() called on cpu#0

(kgdb) bt
#0  boot (howto=260) at ../../kern/kern_shutdown.c:268
#1  0xf0137434 in panic (fmt=0xf01161c8 "from debugger") at ../../kern/kern_shutdown.c:430
#2  0xf01161e5 in db_panic (addr=-266405791, have_addr=0, count=-1, modif=0xf9380ccc "") at ../../ddb/db_command.c:432
#3  0xf01160c5 in db_command (last_cmdp=0xf0225514, cmd_table=0xf0225374, aux_cmd_tablep=0xf0239024) at
../../ddb/db_command.c:332
#4  0xf0116252 in db_command_loop () at ../../ddb/db_command.c:454
#5  0xf0118963 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6  0xf01ef5f4 in kdb_trap (type=3, code=0, regs=0xf9380dbc) at ../../i386/i386/db_interface.c:157
#7  0xf02010a8 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -114249312, tf_esi = 256, tf_ebp = -113766912, 
      tf_isp = -113766940, tf_ebx = -266339399, tf_edx = -266405844, tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err = 0, 
      tf_eip = -266405791, tf_cs = 8, tf_eflags = 598, tf_esp = -266405860, tf_ss = -267160698}) at ../../i386/i386/trap.c:507
#8  0xf01ef861 in Debugger (msg=0xf0137386 "panic") at ../../i386/i386/db_interface.c:316
#9  0xf013742b in panic (fmt=0xf01ffbb9 "rslock: cpu: %d, addr: 0x%08x, lock: 0x%08x") at ../../kern/kern_shutdown.c:428
#10 0xf01ffbb9 in bsl1 ()
#11 0xf01e1e2c in vm_object_terminate (object=0xf024b014) at ../../vm/vm_object.c:444
#12 0xf0157191 in vrele (vp=0xf930b1a0) at ../../kern/vfs_subr.c:1310
#13 0xf01d0b6a in ffs_unmount (mp=0xf1173c00, mntflags=524288, p=0xf930f340) at ../../ufs/ffs/ffs_vfsops.c:847
#14 0xf0159636 in dounmount (mp=0xf1173c00, flags=524288, p=0xf930f340) at ../../kern/vfs_syscalls.c:468
#15 0xf01580f5 in vfs_unmountall () at ../../kern/vfs_subr.c:2193
#16 0xf0137047 in boot (howto=0) at ../../kern/kern_shutdown.c:253
#17 0xf0136dd1 in reboot (p=0xf930f340, uap=0xf9380f94) at ../../kern/kern_shutdown.c:147
#18 0xf0201c2f in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 0, tf_esi = 0, tf_ebp = -272640416, tf_isp = -113766428, 
      tf_ebx = 1, tf_edx = -1, tf_ecx = 3, tf_eax = 55, tf_trapno = 7, tf_err = 2, tf_eip = 134514864, tf_cs = 31, 
      tf_eflags = 582, tf_esp = -272640440, tf_ss = 39}) at ../../i386/i386/trap.c:1031
#19 0xf01f013c in Xint0x80_syscall ()
cannot read proc at 0


>How-To-Repeat:

I am getting this reliably by simply running reboot(8)

>Fix:
	
Unknown.  Tor?????
>Release-Note:
>Audit-Trail:

From: Chris Timmons <skynyrd@opus.cts.cwu.edu>
To: freebsd-gnats-submit@freebsd.org
Cc:  Subject: Re: kern/8309
Date: Wed, 14 Oct 1998 10:17:08 -0700 (PDT)

 Added to the record with the permission of the author...
 
 ---------- Forwarded message ----------
 Date: Wed, 14 Oct 1998 04:17:57 +0200
 From: Tor.Egge@fast.no
 To: skynyrd@opus.cts.cwu.edu
 Cc: dt@FreeBSD.ORG, bde@FreeBSD.ORG, jhk@FreeBSD.ORG, dg@FreeBSD.ORG
 Subject: Re: kern/8309
 
 
 > #9  0xf013742b in panic (fmt=0xf01ffbb9 "rslock: cpu: %d, addr: 0x%08x,
 > lock: 0x%08x") at ../../kern/kern_shutdown.c:428
 > #10 0xf01ffbb9 in bsl1 ()
 
 simple_lock (i.e. s_lock) is frameless.
 
 The caller is vinvalbuf.
 
 
 > #11 0xf01e1e2c in vm_object_terminate (object=0xf024b014) at
 > ../../vm/vm_object.c:444
 
 vfs_subr.c has changed recently
 
 dt          1998/10/12 13:14:09 PDT
 
   Modified files:
     sys/kern             vfs_subr.c 
   Log:
   UnVMIO vnodes of block devices when they are no longer in use. (Some
   things, like msdosfs, do not work (panic) on devices with VMIO enabled.
   FFS enable VMIO on mounted devices, and nothing previously disabled it, so,
   after you mounted FFS floppy, you could not mount msdosfs floppy anymore...)
   
   This is mostly a quick before-release fix.
   
   Reviewed by:	bde
   
   Revision  Changes    Path
   1.164     +13 -2     src/sys/kern/vfs_subr.c
 
 That change is broken with regard to locking.
 
 vm_object_terminate might block.  Thus, the vnode interlock should not
 be held.  Instead, a full lock should be held.
 
 Moving the calls to vfs_object_destroy to right before the calls to
 VOP_INACTIVE looks like an easy fix, but that would introduce a
 potential vnode leak, since resident page count might be nonzero
 before vfs_object_destroy is called.  By adding some code to
 vfs_object_destroy, this leak might be plugged.
 
 There is very little time left before 3.0 is released.  I'll leave
 this task to the Release Engineer, expecting him to delegate this to
 somebody else on the CC list.
 
 Index: vfs_subr.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
 retrieving revision 1.165
 diff -u -r1.165 vfs_subr.c
 --- vfs_subr.c	1998/10/13 08:24:41	1.165
 +++ vfs_subr.c	1998/10/14 01:15:57
 @@ -1306,8 +1316,13 @@
  	struct vnode* vp;
  {
  	if (vp->v_type == VBLK && vp->v_object != NULL &&
 -	    vp->v_object->ref_count == 0)
 +	    vp->v_object->ref_count == 0) {
  		vm_object_terminate(vp->v_object);
 +		simple_lock(&vp->v_interlock);
 +		if (VSHOULDFREE(vp))
 +			vfree(vp);
 +		simple_unlock(&vp->v_interlock);
 +	}
  }
  
  /*
 @@ -1336,7 +1351,6 @@
  
  	if (vp->v_usecount == 1) {
  
 -		vfs_object_destroy(vp);
  		vp->v_usecount--;
  		if (VSHOULDFREE(vp))
  			vfree(vp);
 @@ -1346,6 +1360,7 @@
  	 * vrele, we explicitly lock the vnode before calling VOP_INACTIVE.
  	 */
  		if (vn_lock(vp, LK_EXCLUSIVE | LK_INTERLOCK, p) == 0) {
 +			vfs_object_destroy(vp);
  			VOP_INACTIVE(vp, p);
  		}
  
 @@ -1381,7 +1396,6 @@
  
  	if (vp->v_usecount == 1) {
  
 -		vfs_object_destroy(vp);
  		vp->v_usecount--;
  		if (VSHOULDFREE(vp))
  			vfree(vp);
 @@ -1391,6 +1405,7 @@
  	 * vrele, we explicitly lock the vnode before calling VOP_INACTIVE.
  	 */
  		simple_unlock(&vp->v_interlock);
 +		vfs_object_destroy(vp);
  		VOP_INACTIVE(vp, p);
  
  	} else {
 
 - Tor Egge
 
State-Changed-From-To: open->closed  
State-Changed-By: cwt 
State-Changed-When: Wed Oct 14 13:43:57 PDT 1998 
State-Changed-Why:  
The changes to vfs_subr.c which caused the problem are reverted in 
version 1.166 of that file, and I can no longer reproduce the problem. 
>Unformatted:
