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>