Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Mar 2006 16:52:07 -0500
From:      Kris Kennaway <kris@obsecurity.org>
To:        Kris Kennaway <kris@obsecurity.org>
Cc:        sparc64@FreeBSD.org
Subject:   Re: TODO list status update
Message-ID:  <20060321215207.GA23908@xor.obsecurity.org>
In-Reply-To: <20060320230528.GA79866@xor.obsecurity.org>
References:  <441955A7.1020204@samsco.org> <20060316140435.K95579@newtrinity.zeist.de> <20060316190305.GA25561@xor.obsecurity.org> <20060320165139.D98160@newtrinity.zeist.de> <20060320183227.GA74259@xor.obsecurity.org> <20060320230528.GA79866@xor.obsecurity.org>

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

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

On Mon, Mar 20, 2006 at 06:05:28PM -0500, Kris Kennaway wrote:
> On Mon, Mar 20, 2006 at 01:32:27PM -0500, Kris Kennaway wrote:
> > On Mon, Mar 20, 2006 at 04:51:39PM +0100, Marius Strobl wrote:
> >=20
> > > foreign pcpu structs. Could you please test whether the
> > > patch at:
> > > http://alchemy.franken.de/~marius/ipi.diff
> > > fixes this?
> >=20
> > This patch doesn't cause immediate problems (i.e. it boots), but I ran
> > stress2 and it instantly panicked with

When I disabled the stress2 thread test (which causes the panic below)
the e4500 survived the night running the rest of stress2.  That's good
news since it panics fairly easily without your patch.

Thanks!

Kris

> After about a dozen attempts that just caused fatal resets after the
> panic, I got one that entered DDB properly:
>=20
> panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ ../.=
./../vm/vm_map.c:2993
>=20
> db> wh
> Tracing pid 523 tid 100099 td 0xfffff80045b9e560
> panic() at panic+0x164
> _mtx_lock_sleep() at _mtx_lock_sleep+0x40
> _mtx_lock_flags() at _mtx_lock_flags+0xb8
> _vm_map_lock_read() at _vm_map_lock_read+0x1c
> vm_map_lookup() at vm_map_lookup+0x1c
> vm_fault() at vm_fault+0x68
> trap_pfault() at trap_pfault+0x1a8
> trap() at trap+0x2b0
> -- fast data access mmu miss tar=3D0xe85a4000 %o7=3D0xc02f7728 --
> vm_map_entry_splay() at vm_map_entry_splay+0x10
> vm_map_find() at vm_map_find+0x34
> kmem_alloc_nofault() at kmem_alloc_nofault+0x44
> pmap_pinit() at pmap_pinit+0x30
> vmspace_zinit() at vmspace_zinit+0x14
> slab_zalloc() at slab_zalloc+0x264
> uma_zone_slab() at uma_zone_slab+0x1ac
> uma_zalloc_bucket() at uma_zalloc_bucket+0x1b4
> uma_zalloc_arg() at uma_zalloc_arg+0x3dc
> vmspace_alloc() at vmspace_alloc+0x14
> vmspace_fork() at vmspace_fork+0x24
> vm_forkproc() at vm_forkproc+0xe4
> fork1() at fork1+0xf1c
> fork() at fork+0x10
> syscall() at syscall+0x2dc
> -- syscall (2, FreeBSD ELF64, fork) %o7=3D0x101f18 --
> userland() at 0x403b74e8
> user trace: trap %o7=3D0x101f18
> pc 0x403b74e8, sp 0x7fdffffdf81
> pc 0x101214, sp 0x7fdffffe0d1
> pc 0x4020cd74, sp 0x7fdffffe191
> done
> db> show locks
> exclusive sleep mutex system map r =3D 0 (0xfffff802bfd000d8) locked @ vm=
/vm_map.c:1096
> exclusive sx user map r =3D 0 (0xfffff80042e56cd0) locked @ vm/vm_map.c:2=
485
>=20
> Kris


--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD4DBQFEIHWHWry0BWjoQKURAtYiAJUYXGie9b8/5NQ6D0Voc8vh7mpCAKDNsftc
Ns1k72wZsSo/c1OP+uRd3Q==
=jIDz
-----END PGP SIGNATURE-----

--VS++wcV0S1rZb1Fb--



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