Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Feb 2004 00:54:09 -0800
From:      Kris Kennaway <kris@obsecurity.org>
To:        Thomas Moestl <t.moestl@tu-bs.de>
Cc:        Kris Kennaway <kris@obsecurity.org>
Subject:   Re: "panic: trap: fast data access mmu miss" on 5.2-C
Message-ID:  <20040205085409.GA12282@xor.obsecurity.org>
In-Reply-To: <20040201164950.GB713@timesink.dyndns.org>
References:  <20040201105032.GA17856@xor.obsecurity.org> <20040201164950.GB713@timesink.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> >=20
> > panic: trap: fast data access mmu miss
> > at line 364 in file /var/portbuild/sparc64/src-client/sys/sparc64/sparc=
64/trap.c
> > cpuid =3D 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=3D0x4410000000 %o7=3D0xc005e34c --
> > 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/sparc=
64/trap.ccpuid =3D 0;
> > Debugger("panic")
> > Stopped at      Debugger+0x1c:  ta              %xcc, 1
> > db>
>=20
> 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().
>=20
> 	- Thomas
>=20
> --=20
> Thomas Moestl	<t.moestl@tu-bs.de>	http://www.tu-bs.de/~y0015675/
> 		<tmm@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=3D0 %o7=3D0xc0114a0c
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@enigma:~ swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/da0b          530144        0   530144     0%
--YZ5djTAD1cGYuMQK
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)

iD8DBQFAIgSxWry0BWjoQKURAogpAJ9+5O2D6SWlIip+07kzWtUQvGIuRQCgmg8U
zgxFkks59tOQD/zj3eTYYB0=
=g3yy
-----END PGP SIGNATURE-----

--YZ5djTAD1cGYuMQK--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040205085409.GA12282>