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>