Date: Fri, 16 Dec 2011 17:10:31 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Subject: Re: sparc64 r228561 panic: kmem_suballoc: bad status return of 3 Message-ID: <20111216161031.GA2371@alchemy.franken.de> In-Reply-To: <20111216111922.GA99512@mech-cluster241.men.bris.ac.uk> References: <20111216084048.GA98967@mech-cluster241.men.bris.ac.uk> <20111216103720.GA853@alchemy.franken.de> <20111216111922.GA99512@mech-cluster241.men.bris.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 16, 2011 at 11:19:22AM +0000, Anton Shterenlikht wrote: > On Fri, Dec 16, 2011 at 11:37:20AM +0100, Marius Strobl wrote: > > On Fri, Dec 16, 2011 at 08:40:48AM +0000, Anton Shterenlikht wrote: > > > Updating from r216048 to r228561 on sparc64, > > > with sys/conf/newvers.sh changed to REVISION="9.9". > > > > > > Trinscribed by hand: > > > > > > FreeBSD 9.9-CURRENT #3 r228561M: > > > > > > panic: kmem_suballoc: bad status return of 3 > > > KDB: enter: panic > > > [ thread pid 0 tid 0 ] > > > Stopped at 0x02937e0: ta %xcc,1 > > > db> > > > > > > The keyboard froze, couldn't get a bt, > > > required a cold reboot. > > > > > > My /etc/make.conf and kernel config files are below. > > > > > > Any advice? > > > > > > > Hrm, doesn't look like I can reproduce this. What machine model is > > that and how much RAM does it have? > > >From dmesg: > > real memory = 2147483648 (2048 MB) > avail memory = 2079449088 (1983 MB) > cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) > > > Do you use any loader tuneables? > > I don't think so. You mean like /boot/loader.conf? > I haven't got this file at all. > Even with a Blade 1500, which is the closest match to your machine that I have, and a kernel built with your configuration file I can't reproduce this using r228583. I'd suggest to test with a kernel built using an empty object directory and without any local modifications. If that still doesn't solve the problem given that there isn't even a backtrace I just can suggest to do a binary search for the offending commit, probably accounting especially for the changes to the VM within the window of revisions in question. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111216161031.GA2371>