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

Kris Kennaway kris at obsecurity.org
Thu Feb 5 00:54:13 PST 2004


On Sun, Feb 01, 2004 at 05:49:50PM +0100, Thomas Moestl wrote:
> On Sun, 2004/02/01 at 02:50:32 -0800, Kris Kennaway wrote:
> > I updated the sparc64 package clients to 5.2-CURRENT 2 days ago, and
> > one of them panicked today:
> > 
> > panic: trap: fast data access mmu miss
> > at line 364 in file /var/portbuild/sparc64/src-client/sys/sparc64/sparc64/trap.c
> > cpuid = 0;
> > Debugger("panic")
> > Stopped at      Debugger+0x1c:  ta              %xcc, 1
> > db> trace
> > __panic() at __panic+0x17c
> > trap() at trap+0x3f0
> > -- fast data access mmu miss tar=0x4410000000 %o7=0xc005e34c --
> > db_read_bytes() at db_read_bytes+0x1c
> > db_stack_trace_cmd() at db_stack_trace_cmd+0x1cc
> > db_print_backtrace() at db_print_backtrace+0x18
> > backtrace() at backtrace+0x10
> > witness_checkorder() at witness_checkorder+0x6b0
> > [...]
> > fork_exit() at fork_exit+0x8c
> > fork_trampoline() at fork_trampoline+0x8
> > ofw_pci_default_intr_pending() at ofw_pci_default_intr_pending+0x38
> > panic: trap: fast data access mmu miss
> > at line 364 in file /var/portbuild/sparc64/src-client/sys/sparc64/sparc64/trap.ccpuid = 0;
> > Debugger("panic")
> > Stopped at      Debugger+0x1c:  ta              %xcc, 1
> > db>
> 
> 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().
> 
> 	- Thomas
> 
> -- 
> Thomas Moestl	<t.moestl at tu-bs.de>	http://www.tu-bs.de/~y0015675/
> 		<tmm at FreeBSD.org>	http://people.FreeBSD.org/~tmm/
> "In my opinion, television validates existence."
> 						-- Calvin and Hobbes

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

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%
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20040205/69678401/attachment-0001.bin


More information about the freebsd-sparc64 mailing list