From owner-freebsd-current@FreeBSD.ORG  Thu Apr 17 09:22:23 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id BA37637B401; Thu, 17 Apr 2003 09:22:23 -0700 (PDT)
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by mx1.FreeBSD.org (Postfix) with SMTP
	id 59CB843FB1; Thu, 17 Apr 2003 09:22:22 -0700 (PDT)
	(envelope-from iedowse@maths.tcd.ie)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa13792@salmon>; 17 Apr 2003 17:22:21 +0100 (BST)
To: Ruslan Ermilov <ru@freebsd.org>
In-Reply-To: Your message of "Thu, 17 Apr 2003 14:32:18 +0300."
             <20030417113218.GA96808@sunbay.com> 
Date: Thu, 17 Apr 2003 17:22:20 +0100
From: Ian Dowse <iedowse@maths.tcd.ie>
Message-ID: <200304171722.aa13792@salmon.maths.tcd.ie>
cc: current@freebsd.org
cc: Andrew Gallatin <gallatin@cs.duke.edu>
cc: Nate Lawson <nate@root.org>
Subject: Re: Your locking and rman changes to pci/if_* 
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2003 16:22:24 -0000

In message <20030417113218.GA96808@sunbay.com>, Ruslan Ermilov writes:
>
>Yes, Ian's patch did the trick.  Let me know if you still want a backtrace,
>and should it be against the kernel with debug information or not.

FYI, below is the backtrace that I got. The fact that the trap was
in softclock() was a good indication of a missing callout_stop().
It looks BTW, as if we convert some kernel page faults into witness
panics, which is not so good... I think it is limited to cases where
we page fault without Giant, but with a spin lock held (in this
case callout_lock).

Ian

	ukphy0: detached
	miibus0: detached
	dc0: detached
	panic: blockable sleep lock (sleep mutex) Giant @ vm/vm_fault.c:206
	Stack backtrace:
	backtrace(c037eb83,c0428d40,c038146d,c8721a18,1) at backtrace+0x17
	panic(c038146d,c038fff9,c037e279,c038fb5e,ce) at panic+0x96
	witness_lock(c03f4fe0,8,c038fb5e,ce,c037fb2b) at witness_lock+0xaf
	_mtx_lock_flags(c03f4fe0,0,c038fb55,ce,1) at _mtx_lock_flags+0xb1
	vm_fault(c0847000,deadc000,1,0,c0bb5980) at vm_fault+0x59
	trap_pfault(c8721c4c,0,deadc0e6,1,deadc0e6) at trap_pfault+0x181
	trap(18,c0370010,10,c01e57b0,c188fe40) at trap+0x3ed
	calltrap() at calltrap+0x5
	--- trap 0xc, eip = 0xc0214fd3, esp = 0xc8721c8c, ebp = 0xc8721cb0 ---
	softclock(0,0,c037c7db,232,1) at softclock+0x83
	ithread_loop(c0bb3180,c8721d48,c037c66b,314,0) at ithread_loop+0x182
	fork_exit(c01f3060,c0bb3180,c8721d48) at fork_exit+0xc4
	fork_trampoline() at fork_trampoline+0x1a
	--- trap 0x1, eip = 0, esp = 0xc8721d7c, ebp = 0 ---