From owner-cvs-all  Fri Oct 25 11: 3:55 2002
Delivered-To: cvs-all@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5FDF637B401; Fri, 25 Oct 2002 11:03:54 -0700 (PDT)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 0389C43E6A; Fri, 25 Oct 2002 11:03:53 -0700 (PDT)
	(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id EAA01187;
	Sat, 26 Oct 2002 04:03:47 +1000
Date: Sat, 26 Oct 2002 04:14:57 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: John Baldwin <jhb@FreeBSD.org>, <cvs-all@FreeBSD.org>,
	<cvs-committers@FreeBSD.org>
Subject: Re: cvs commit: src/sys/kern kern_mutex.c 
In-Reply-To: <18323.1035554446@critter.freebsd.dk>
Message-ID: <20021026040625.U4817-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG

On Fri, 25 Oct 2002, Poul-Henning Kamp wrote:

> PS: That reminds me, I've sometimes wondered if we should have a
> global string pointer where one could leave a panic hint,
> that could make the above code look something like:
>
> 	{
> 	struct mtx tmp;
>
> 	[...]
> 	/* See if we can read/write the mutex */
> 	panic_hint("Mutex in wrong kind of RAM");
> 	bcopy(mp, &tmp, sizeof tmp);
> 	bcopy(&tmp, mp, sizeof tmp);
> 	panic_hint(NULL);
>
> And if explode on one of the bcopy() panic would leave a hint
> about what the problem is:
>
> 	panic(blablabla)
> 	This may be why:  Mutex in wrong kind of RAM.
> 	Hint from: mtx_validate() line 886 in ../../../kern/kern_mutex.c
>
> Just an idea...

No need.  Memory access errors are very easy to debug since debuggers show
a context with the precise instruction and function that caused the error.
Anyone how can debug them doesn't need a hint about why the function might
cause a memory access error.  Panics are not so easy to debug, since the
context and restartability are messed up by calling panic().

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message