Date: Thu, 5 Feb 2004 15:35:36 +0100 From: Thomas Moestl <t.moestl@tu-bs.de> To: Kris Kennaway <kris@obsecurity.org> Cc: sparc64@freebsd.org Subject: Re: "panic: trap: fast data access mmu miss" on 5.2-C Message-ID: <20040205143536.GA712@timesink.dyndns.org> In-Reply-To: <20040205085409.GA12282@xor.obsecurity.org> References: <20040201105032.GA17856@xor.obsecurity.org> <20040201164950.GB713@timesink.dyndns.org> <20040205085409.GA12282@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@enigma:~ swapinfo > Device 1K-blocks Used Avail Capacity > /dev/da0b 530144 0 530144 0% I'll look into that. - Thomas -- Thomas Moestl <t.moestl@tu-bs.de> http://www.tu-bs.de/~y0015675/ <tmm@FreeBSD.org> http://people.FreeBSD.org/~tmm/ "I was going to be a neo-deconstructivist but Mom wouldn't let me." -- Calvin and Hobbes
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040205143536.GA712>