"panic: trap: fast data access mmu miss" on 5.2-C

Thomas Moestl t.moestl at tu-bs.de
Thu Feb 5 06:34:03 PST 2004

On Thu, 2004/02/05 at 00:54:09 -0800, Kris Kennaway wrote:
> On Sun, Feb 01, 2004 at 05:49:50PM +0100, Thomas Moestl wrote:
> > Looks like the back trace ran off the end of the stack;
> > db_stack_trace_cmd() only handles the usual starting points of kernel
> > stacks (traps from userland), but not freshly forked processes (or
> > kernel threads). The attached patch should fix that by initializing
> > the fr_pc and fr_fp fields of the first frame to 0 in cpu_fork().

Did you get a witness backtrace ending in fork_trampoline() since?
> I'm getting another panic with this patch (transcribed manually):
> fast data access mmu miss tar=0 %o7=0xc0114a0c
> copyin+0x5c
> pipe_write+0x568
> dofilewrite+0xec
> write+0x3c
> syscall+0x314

Is it possible that this is caused by the bug which rwatson fixed in
r1.166 of sys/sys_pipe.c (i.e. do you have r1.165 of that file)?
> Also, dumping seems to be broken:
> db> call doadump
> Insufficient space on device (need 268436992, have 0), refusing to dump.
> The dump device is set to /dev/da0b, and
> kkenn at enigma:~ swapinfo
> Device          1K-blocks     Used    Avail Capacity
> /dev/da0b          530144        0   530144     0%

I'll look into that.

	- Thomas

Thomas Moestl	<t.moestl at tu-bs.de>	http://www.tu-bs.de/~y0015675/
		<tmm at FreeBSD.org>	http://people.FreeBSD.org/~tmm/
"I was going to be a neo-deconstructivist but Mom wouldn't let me."
						-- Calvin and Hobbes

More information about the freebsd-sparc64 mailing list