Date: Sat, 26 Oct 2002 04:14:57 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> 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 Message-ID: <20021026040625.U4817-100000@gamplex.bde.org> In-Reply-To: <18323.1035554446@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021026040625.U4817-100000>