From owner-freebsd-sparc64@FreeBSD.ORG Sun Jan 8 16:41:36 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44C3D106566B; Sun, 8 Jan 2012 16:41:36 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id CE0F58FC0A; Sun, 8 Jan 2012 16:41:35 +0000 (UTC) Received: from happy.home.yamagi.org (g224129135.adsl.alicedsl.de [92.224.129.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTPSA id 1FE951666334; Sun, 8 Jan 2012 17:41:33 +0100 (CET) Date: Sun, 8 Jan 2012 17:41:12 +0100 From: Yamagi Burmeister To: kostikbel@gmail.com Message-Id: <20120108174112.50e030ba.lists@yamagi.org> In-Reply-To: <20120102063700.GF50300@deviant.kiev.zoral.com.ua> References: <20111226220756.GR50300@deviant.kiev.zoral.com.ua> <20120102063700.GF50300@deviant.kiev.zoral.com.ua> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sun__8_Jan_2012_17_41_12_+0100_kuU+DV/Jqkt+Aq8r" Cc: amd64@freebsd.org, arch@freebsd.org, sparc64@freebsd.org Subject: Re: AVX X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 16:41:36 -0000 --Signature=_Sun__8_Jan_2012_17_41_12_+0100_kuU+DV/Jqkt+Aq8r Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've tested your patch on a Core2Duo with XSAVE but (of course) without AVX on 10-CURRENT as of today (r229812): CPU: Intel(R) Core(TM)2 Duo CPU T6670 @ 2.20GHz (2194.55-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x1067a Family =3D 6 Model =3D 17 Stepping =3D 10 Features=3D0xbfebfbff Features2=3D0x408e3bd AMD Features=3D0x20100800 AMD Features2=3D0x1=20 Everything's fine: - System is booting without a problem - All applications are working - AVX applications are still failing with SIGILL But there's one problem: While a shutdown (shutdown -p now) is always successfull a reboot (shutdown -r now) and suspend (zzz) are resulting=20 in a double panic. The first panic is a "Fatal trap 9: general protection fault while in kernel mode" on "cpuid =3D 1; apic id =3D 01". The process is always "idle: cpu1". The second panic is also "Fatal trap 9: general protection fault while in kernel mode" but with "cpuid =3D 0; apic id =3D 00". The process is always "init".=20 Since it's a dual core cpu, one panic for each processor core?=20 I'm unable to get a core dump and ddb is unresponsive to any keyboard input. A serial console is unavailable, since it's a laptop... Nevertheless I've uploaded screenshots of both panics to: =20 http://deponie.yamagi.org/freebsd/debug/avx=20 On Mon, 2 Jan 2012 08:37:00 +0200 Kostik Belousov wrote: > The patch > http://people.freebsd.org/~kib/misc/avx.2.patch > is the commit candidate. Compared with avx.1.patch, it includes > several bugfixes, some move of code around, and finishes the > implementation of getcontextx(3) for non-x86 architectures. >=20 > Please note that variant of getcontextx() is required for deferred > signal delivery from libthr. This is the reason for Cc:ing sparc64@, > could somebody test the patch on this architecture ? I used the > http://people.freebsd.org/~kib/misc/defer_sig.c to test deferred > delivery on amd64. >=20 > Another missed testing point is machines capable of XSAVE but lacking > AVX extensions. I think most Core2 fall into this category, but my Core2 > machine is disassembled. Could anybody test the patch on non-SandyBridge > machine having XSAVE support ? You can check the capability using > ports/sysutils/x86info or looking at the early boot Features2 line, > which shall contain the XSAVE. --=20 Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --Signature=_Sun__8_Jan_2012_17_41_12_+0100_kuU+DV/Jqkt+Aq8r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8JxzwACgkQWTjlg++8y8t4jgCfWd8oyl3al8qrCbC2A5ZbiA7U 24UAnRQJoOVK7JWDzrXpCBGKJ6BnrNMn =kXS0 -----END PGP SIGNATURE----- --Signature=_Sun__8_Jan_2012_17_41_12_+0100_kuU+DV/Jqkt+Aq8r-- From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 9 11:07:13 2012 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3AD81065677 for ; Mon, 9 Jan 2012 11:07:13 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B15508FC22 for ; Mon, 9 Jan 2012 11:07:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q09B7DeN042310 for ; Mon, 9 Jan 2012 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q09B7DHH042308 for freebsd-sparc64@FreeBSD.org; Mon, 9 Jan 2012 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Jan 2012 11:07:13 GMT Message-Id: <201201091107.q09B7DHH042308@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 11:07:13 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/162513 sparc64 mpt(4), mptutil(8) reports variable, erroneous drive i o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption s sparc/107087 sparc64 [hang] system is hung during boot from CD o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 7 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Mon Jan 9 22:20:50 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A69C106566C; Mon, 9 Jan 2012 22:20:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy.sentex.ca (freebsd-legacy.sentex.ca [IPv6:2607:f3e0:0:3::6502:9a]) by mx1.freebsd.org (Postfix) with ESMTP id CF7B08FC15; Mon, 9 Jan 2012 22:20:49 +0000 (UTC) Received: from freebsd-legacy.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy.sentex.ca (8.14.5/8.14.5) with ESMTP id q09MKnG6092917; Mon, 9 Jan 2012 22:20:49 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy.sentex.ca (8.14.5/8.14.5/Submit) id q09MKnv6092916; Mon, 9 Jan 2012 22:20:49 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 9 Jan 2012 22:20:49 GMT Message-Id: <201201092220.q09MKnv6092916@freebsd-legacy.sentex.ca> X-Authentication-Warning: freebsd-legacy.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 22:20:50 -0000 TB --- 2012-01-09 20:34:25 - tinderbox 2.8 running on freebsd-legacy.sentex.ca TB --- 2012-01-09 20:34:25 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2012-01-09 20:34:25 - cleaning the object tree TB --- 2012-01-09 20:34:44 - cvsupping the source tree TB --- 2012-01-09 20:34:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca -s /usr/home/tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2012-01-09 20:34:50 - building world TB --- 2012-01-09 20:34:50 - CROSS_BUILD_TESTING=YES TB --- 2012-01-09 20:34:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-09 20:34:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-09 20:34:50 - SRCCONF=/dev/null TB --- 2012-01-09 20:34:50 - TARGET=sparc64 TB --- 2012-01-09 20:34:50 - TARGET_ARCH=sparc64 TB --- 2012-01-09 20:34:50 - TZ=UTC TB --- 2012-01-09 20:34:50 - __MAKE_CONF=/dev/null TB --- 2012-01-09 20:34:50 - cd /src TB --- 2012-01-09 20:34:50 - /usr/bin/make -B buildworld >>> World build started on Mon Jan 9 20:34:51 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jan 9 22:01:42 UTC 2012 TB --- 2012-01-09 22:01:42 - generating LINT kernel config TB --- 2012-01-09 22:01:42 - cd /src/sys/sparc64/conf TB --- 2012-01-09 22:01:42 - /usr/bin/make -B LINT TB --- 2012-01-09 22:01:42 - cd /src/sys/sparc64/conf TB --- 2012-01-09 22:01:42 - /usr/sbin/config -m LINT TB --- 2012-01-09 22:01:42 - building LINT kernel TB --- 2012-01-09 22:01:42 - CROSS_BUILD_TESTING=YES TB --- 2012-01-09 22:01:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-01-09 22:01:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-01-09 22:01:42 - SRCCONF=/dev/null TB --- 2012-01-09 22:01:42 - TARGET=sparc64 TB --- 2012-01-09 22:01:42 - TARGET_ARCH=sparc64 TB --- 2012-01-09 22:01:42 - TZ=UTC TB --- 2012-01-09 22:01:42 - __MAKE_CONF=/dev/null TB --- 2012-01-09 22:01:42 - cd /src TB --- 2012-01-09 22:01:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jan 9 22:01:42 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror vnode_if.c :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel nfs_nfsdsubs.o(.data+0x0): undefined reference to `sysctl__vfs_nfsd_children' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-01-09 22:20:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-01-09 22:20:49 - ERROR: failed to build LINT kernel TB --- 2012-01-09 22:20:49 - 4909.68 user 816.33 system 6383.91 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Tue Jan 10 13:46:11 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B24D106564A for ; Tue, 10 Jan 2012 13:46:11 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 31DC48FC12 for ; Tue, 10 Jan 2012 13:46:11 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirj.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Rkc1h-0002mH-P1; Tue, 10 Jan 2012 13:46:09 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Rkc1h-0001ir-Ib; Tue, 10 Jan 2012 13:46:09 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id q0ADk1V3007643; Tue, 10 Jan 2012 13:46:01 GMT (envelope-from mexas@bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id q0ADk1r1007642; Tue, 10 Jan 2012 13:46:01 GMT (envelope-from mexas@bris.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bris.ac.uk using -f Date: Tue, 10 Jan 2012 13:46:01 +0000 From: Anton Shterenlikht To: Anton Shterenlikht Message-ID: <20120110134600.GA7617@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> <20111216161031.GA2371@alchemy.franken.de> <20120106112126.GA69964@mech-cluster241.men.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120106112126.GA69964@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org, Marius Strobl Subject: Re: r223378 panic [Re: sparc64 r228561 panic: kmem_suballoc: bad status return of 3] X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 13:46:11 -0000 On Fri, Jan 06, 2012 at 11:21:27AM +0000, Anton Shterenlikht wrote: > On Fri, Dec 16, 2011 at 05:10:31PM +0100, Marius Strobl wrote: > > 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. > > It took a while. > > 223377 - ok > 223378 - panic > > # svn up -r 223378 > Updating '.': > U sys/sparc64/include/tsb.h > U sys/sparc64/include/vmparam.h > Updated to revision 223378. > > # svn diff -c 223378 > Index: sys/sparc64/include/tsb.h > =================================================================== > --- sys/sparc64/include/tsb.h (revision 223377) > +++ sys/sparc64/include/tsb.h (revision 223378) > @@ -50,7 +50,6 @@ > extern vm_size_t tsb_kernel_mask; > extern vm_size_t tsb_kernel_size; > extern vm_paddr_t tsb_kernel_phys; > -extern u_int tsb_kernel_ldd_phys; > > static __inline struct tte * > tsb_vpntobucket(pmap_t pm, vm_offset_t vpn) > Index: sys/sparc64/include/vmparam.h > =================================================================== > --- sys/sparc64/include/vmparam.h (revision 223377) > +++ sys/sparc64/include/vmparam.h (revision 223378) > @@ -218,7 +218,7 @@ > * is the total KVA space allocated for kmem_map. > */ > #ifndef VM_KMEM_SIZE_SCALE > -#define VM_KMEM_SIZE_SCALE (3) > +#define VM_KMEM_SIZE_SCALE (tsb_kernel_ldd_phys == 0 ? 3 : 1) > #endif > > /* > @@ -238,6 +238,7 @@ > > #define UMA_MD_SMALL_ALLOC > > +extern u_int tsb_kernel_ldd_phys; > extern vm_offset_t vm_max_kernel_address; > > /* > I just realised that I have another blade 1500 silver, which runs 226827: FreeBSD 9.0-RC1 #2 r226827: Thu Oct 27 15:51:42 BST 2011 root@mech-as222.men.bris.ac.uk:/usr/obj/usr/src/sys/DALET sparc64 WARNING: WITNESS option enabled, expect reduced performance. real memory = 5368709120 (5120 MB) avail memory = 5230305280 (4988 MB) cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) However, if I try to use that revision on the problem box, I still get this panic. What's going on? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-sparc64@FreeBSD.ORG Wed Jan 11 19:41:52 2012 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BDD11065672 for ; Wed, 11 Jan 2012 19:41:52 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id DA8728FC0A for ; Wed, 11 Jan 2012 19:41:51 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q0BJfYG5049345; Wed, 11 Jan 2012 20:41:35 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q0BJfYop049344; Wed, 11 Jan 2012 20:41:34 +0100 (CET) (envelope-from marius) Date: Wed, 11 Jan 2012 20:41:34 +0100 From: Marius Strobl To: Anton Shterenlikht Message-ID: <20120111194134.GC44286@alchemy.franken.de> References: <20111216084048.GA98967@mech-cluster241.men.bris.ac.uk> <20111216103720.GA853@alchemy.franken.de> <20111216111922.GA99512@mech-cluster241.men.bris.ac.uk> <20111216161031.GA2371@alchemy.franken.de> <20120106112126.GA69964@mech-cluster241.men.bris.ac.uk> <20120110134600.GA7617@mech-cluster241.men.bris.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120110134600.GA7617@mech-cluster241.men.bris.ac.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: r223378 panic [Re: sparc64 r228561 panic: kmem_suballoc: bad status return of 3] X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 19:41:52 -0000 On Tue, Jan 10, 2012 at 01:46:01PM +0000, Anton Shterenlikht wrote: > On Fri, Jan 06, 2012 at 11:21:27AM +0000, Anton Shterenlikht wrote: > > On Fri, Dec 16, 2011 at 05:10:31PM +0100, Marius Strobl wrote: > > > 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. > > > > It took a while. > > > > 223377 - ok > > 223378 - panic > > > > # svn up -r 223378 > > Updating '.': > > U sys/sparc64/include/tsb.h > > U sys/sparc64/include/vmparam.h > > Updated to revision 223378. > > > > # svn diff -c 223378 > > Index: sys/sparc64/include/tsb.h > > =================================================================== > > --- sys/sparc64/include/tsb.h (revision 223377) > > +++ sys/sparc64/include/tsb.h (revision 223378) > > @@ -50,7 +50,6 @@ > > extern vm_size_t tsb_kernel_mask; > > extern vm_size_t tsb_kernel_size; > > extern vm_paddr_t tsb_kernel_phys; > > -extern u_int tsb_kernel_ldd_phys; > > > > static __inline struct tte * > > tsb_vpntobucket(pmap_t pm, vm_offset_t vpn) > > Index: sys/sparc64/include/vmparam.h > > =================================================================== > > --- sys/sparc64/include/vmparam.h (revision 223377) > > +++ sys/sparc64/include/vmparam.h (revision 223378) > > @@ -218,7 +218,7 @@ > > * is the total KVA space allocated for kmem_map. > > */ > > #ifndef VM_KMEM_SIZE_SCALE > > -#define VM_KMEM_SIZE_SCALE (3) > > +#define VM_KMEM_SIZE_SCALE (tsb_kernel_ldd_phys == 0 ? 3 : 1) > > #endif > > > > /* > > @@ -238,6 +238,7 @@ > > > > #define UMA_MD_SMALL_ALLOC > > > > +extern u_int tsb_kernel_ldd_phys; > > extern vm_offset_t vm_max_kernel_address; > > > > /* > > > > I just realised that I have another blade 1500 silver, > which runs 226827: > > FreeBSD 9.0-RC1 #2 r226827: Thu Oct 27 15:51:42 BST 2011 > root@mech-as222.men.bris.ac.uk:/usr/obj/usr/src/sys/DALET sparc64 > WARNING: WITNESS option enabled, expect reduced performance. > real memory = 5368709120 (5120 MB) > avail memory = 5230305280 (4988 MB) > cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) > > However, if I try to use that revision on the > problem box, I still get this panic. What's going on? > So far I didn't have time to look into this. I suspect the issue has to do with the holes USIIIi machines tend to have in their physical memory layout. For a b1k5 with 2GB RAM such a hole might be large enough to trigger some bug in the VM but not trigger with 4GB or as in my case with 1GB. Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Jan 12 18:01:43 2012 Return-Path: Delivered-To: sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 534D5106564A; Thu, 12 Jan 2012 18:01:43 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id E300B8FC13; Thu, 12 Jan 2012 18:01:42 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 260AF2A28CD6; Thu, 12 Jan 2012 19:01:42 +0100 (CET) Date: Thu, 12 Jan 2012 19:01:42 +0100 From: Ed Schouten To: mips@FreeBSD.org, sparc64@FreeBSD.org Message-ID: <20120112180142.GI5300@hoeg.nl> References: <20111227231243.GB1895@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X9OP1fpbq0KufMFh" Content-Disposition: inline In-Reply-To: <20111227231243.GB1895@hoeg.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [Last call] (Finally) migrate MIPS and SPARC64 to libcompiler_rt X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 18:01:43 -0000 --X9OP1fpbq0KufMFh Content-Type: multipart/mixed; boundary="MO4t1VgQTCtsHhID" Content-Disposition: inline --MO4t1VgQTCtsHhID Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, Florian did some quite some testing for me and he can confirm that the patches make libcompiler_rt functional on SPARC64. As far as I know, the ctz/clz issue is also what prevented MIPS64 from working, so I am not aware of any issues that prevent us from switching to libcompiler_rt exclusively. If there are any objections against me committing the following patch, please speak up now! --=20 Ed Schouten WWW: http://80386.nl/ --MO4t1VgQTCtsHhID Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="compiler-rt.diff" Content-Transfer-Encoding: quoted-printable Index: gnu/lib/libgcc/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- gnu/lib/libgcc/Makefile (revision 230014) +++ gnu/lib/libgcc/Makefile (working copy) @@ -15,10 +15,6 @@ =20 .include "${.CURDIR}/../../usr.bin/cc/Makefile.tgt" =20 -.if ${TARGET_CPUARCH} =3D=3D "sparc64" || ${TARGET_CPUARCH} =3D=3D "mips" -LIB=3D gcc -.endif - .PATH: ${GCCDIR}/config/${GCC_CPU} ${GCCDIR}/config ${GCCDIR} =20 CFLAGS+=3D -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED \ Index: lib/libcompiler_rt/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/libcompiler_rt/Makefile (revision 230014) +++ lib/libcompiler_rt/Makefile (working copy) @@ -176,13 +176,11 @@ . endif .endfor =20 -.if ${MACHINE_CPUARCH} !=3D "sparc64" && ${MACHINE_CPUARCH} !=3D "mips" -. if ${MK_INSTALLLIB} !=3D "no" +.if ${MK_INSTALLLIB} !=3D "no" SYMLINKS+=3Dlibcompiler_rt.a ${LIBDIR}/libgcc.a -. endif -. if ${MK_PROFILE} !=3D "no" +.endif +.if ${MK_PROFILE} !=3D "no" SYMLINKS+=3Dlibcompiler_rt_p.a ${LIBDIR}/libgcc_p.a -. endif .endif =20 .if ${MACHINE_CPUARCH} =3D=3D "amd64" || ${MACHINE_CPUARCH} =3D=3D "i386" = || \ @@ -191,5 +189,4 @@ ACFLAGS+=3D-Wa,--noexecstack .endif =20 - .include --MO4t1VgQTCtsHhID-- --X9OP1fpbq0KufMFh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJPDyAFAAoJEG5e2P40kaK7XXYQAIqEPgv9JL2MARl8b9y9lIrM 0MsYMAjBM6TzNBEZbkSgS6A68VxHi2sdY/n8bwLP3/M5SNJaPCg+Deg5/g48olik I8E4M0aDs7lRicQytzkoGeWmZRaA9N5Qn19C7JbaHhPaPNHUcCo1IBYs2E274Kgg 9cSjwZisXizXve3pG90EUU0zomtWT9Lu6hRp0mXIdkH16RcqdyzT5/EAde8TF9Rq KO+JL3Zh3hHiZK+WvrnFy3+cC0C5ADYCbBqhc1jqmMsEwd0unlxf0+6fldC6tcX/ cdea9qgtmlCMdwlieVACW7hKHqqFcO3NU1pWN7k/eS7yTY9/eyUKCDxY7Nibdlii fw2uR1z87/Op9AUcUalTdlfcYEY+gDYwT1q0c+qU9+M7qZQkUFKU8kNvpsRFyb/l 2t+C4KP2gZVi31MqNxtG2w1M79T2mXwkf2dlox5Etq2PHD7Z1tsZ9v55tmAY4CPc ptsx86toTX5KFsy1oKyUfSdCUClWr4DFTE/DvxgCieJWKj1LM/jWZqgja7v435Hf dWU4PBXnJcXYDs1V+j2PSldFmApUf9MSileEVfzRHDYKQjJoMblP32VW+9nbMbu7 u6+I0yK25KVrOovjwPvWv8wvIJNnz5S2bbocpe3/lHxfEHdy6b3rACyrUHUaWK/V alRfOoZ1aYGOMwCpyGR9 =bvPy -----END PGP SIGNATURE----- --X9OP1fpbq0KufMFh-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 13 12:27:01 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A2EB106566B; Fri, 13 Jan 2012 12:27:01 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 964758FC08; Fri, 13 Jan 2012 12:27:00 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 722F32A28CED; Fri, 13 Jan 2012 13:26:56 +0100 (CET) Date: Fri, 13 Jan 2012 13:26:56 +0100 From: Ed Schouten To: "Jayachandran C." Message-ID: <20120113122656.GN5300@hoeg.nl> References: <20111227231243.GB1895@hoeg.nl> <20120112180142.GI5300@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p+IlF8Xh9KY56wTg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mips@freebsd.org, sparc64@freebsd.org Subject: Re: [Last call] (Finally) migrate MIPS and SPARC64 to libcompiler_rt X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 12:27:01 -0000 --p+IlF8Xh9KY56wTg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, * Jayachandran C. , 20120113 13:15: > Is this tested on MIPS with all the ABIs i.e. 32, n32 and 64? If it > is not, let me know... That's a bit of a problem. Florian tested it for me on SPARC64 and based on the bug reports I received at the time I _assume_ MIPS is fixed. If I remember correctly, MIPS32 already worked properly, but it was just MIPS64 that was broken. Still, it would be nice if someone could test it for me. Thanks, --=20 Ed Schouten WWW: http://80386.nl/ --p+IlF8Xh9KY56wTg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJPECMQAAoJEG5e2P40kaK794YP/1Lbk3hfRpVcbgVwgzE7XJx9 i3v3mkOQDx3gDoztgA90/BrhpZ4v3l9UVac5R1lcJd5gzQw76qIMC9gBfy/3roOI 2qd4ON5K4aDD4gtQNNYxYr2JQY2D3gMMOvU2gpJR9HXOWdb3neyZKnSSsn2C7B+Y bESVQnlaZNKSApbj2Fjp0maQVQ987LiD0SsYr7kBZAmVf48lvntEiEYZJ6Q2DoMJ LczdCiJLeU4ildo/svMcssUxZ8f627NmaMJLIr/bzDWpwLI0PkzQN90Y4eZR0Taw ILwv52oJOfhsqyncmRT4BAuDUq9jelNHk7JgOLf/IKgjataGvJyiuPUSOvOLNzSV 7zDstewowSA2G78dSENKfCpqEhDLj325uw3L513iOYzVKEdM7tv4Ix0ONr2YbUWv iHJ5xFueJFYWzXNdTBlRbNz6e+Zk1UoVeBUBgoP5EBolQ8oIi1idR7YeeCRTZLlC pGetzof0B4w+OL8n3mAxUKkCCP6BFtBlTr6CjcZ5OFcu2fgnbDbHGfM+379LG5lL f5hrmEzaSE6gPVZnA1B1Q2PnidZCPMV/2e9kszO+9YbfNZiRcgVXt899qiSyUpNn bPHNi96K3CTqc2TzMnfIvIkw3Wnd6cN+GdzvfP7mdjokjbbiyA0jaEj1Im2Pvbd/ zTEOdsSMqI/SdJb5jQrW =3aWu -----END PGP SIGNATURE----- --p+IlF8Xh9KY56wTg-- From owner-freebsd-sparc64@FreeBSD.ORG Fri Jan 13 12:44:00 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F7F8106564A; Fri, 13 Jan 2012 12:44:00 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0788FC16; Fri, 13 Jan 2012 12:43:59 +0000 (UTC) Received: by werm12 with SMTP id m12so514027wer.13 for ; Fri, 13 Jan 2012 04:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yJ4NmqxeY4ifC80IDcykIUqudsNVQy+ZoTXy93bOQ8U=; b=K9yYJTXXrIZXWV16SoKhrdBPb8/T96bymP8ok9YJdcgJe8HNZjGj/8u9u2//kzV4FT Wa1L+1BRpJ1rrZ1qTFPy4QCqHCgfrm5fxYIMI9hHNNNwaBfUM8hVwSvm9uYAbv0OMOpw wYWEPw1aJwQibgJfo+yYOTL4tgHGQbFjN1ZZs= MIME-Version: 1.0 Received: by 10.216.137.97 with SMTP id x75mr2013860wei.57.1326456938142; Fri, 13 Jan 2012 04:15:38 -0800 (PST) Sender: c.jayachandran@gmail.com Received: by 10.216.54.15 with HTTP; Fri, 13 Jan 2012 04:15:38 -0800 (PST) In-Reply-To: <20120112180142.GI5300@hoeg.nl> References: <20111227231243.GB1895@hoeg.nl> <20120112180142.GI5300@hoeg.nl> Date: Fri, 13 Jan 2012 17:45:38 +0530 X-Google-Sender-Auth: OlRBeZv8QLt1tmMvIDD3NJU7dMg Message-ID: From: "Jayachandran C." To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: mips@freebsd.org, sparc64@freebsd.org Subject: Re: [Last call] (Finally) migrate MIPS and SPARC64 to libcompiler_rt X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 12:44:00 -0000 On Thu, Jan 12, 2012 at 11:31 PM, Ed Schouten wrote: > Hi all, > > Florian did some quite some testing for me and he can confirm that the > patches make libcompiler_rt functional on SPARC64. As far as I know, the > ctz/clz issue is also what prevented MIPS64 from working, so I am not > aware of any issues that prevent us from switching to libcompiler_rt > exclusively. > > If there are any objections against me committing the following patch, > please speak up now! Is this tested on MIPS with all the ABIs i.e. 32, n32 and 64? If it is not, let me know... JC. From owner-freebsd-sparc64@FreeBSD.ORG Sat Jan 14 16:20:13 2012 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5FCA1065676 for ; Sat, 14 Jan 2012 16:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BE6F28FC16 for ; Sat, 14 Jan 2012 16:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0EGKCHG092640 for ; Sat, 14 Jan 2012 16:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0EGKCMQ092639; Sat, 14 Jan 2012 16:20:12 GMT (envelope-from gnats) Resent-Date: Sat, 14 Jan 2012 16:20:12 GMT Resent-Message-Id: <201201141620.q0EGKCMQ092639@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-sparc64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Guy M. Broome" Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBD691065670 for ; Sat, 14 Jan 2012 16:16:42 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id C6E4E8FC15 for ; Sat, 14 Jan 2012 16:16:42 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q0EGGgjR029509 for ; Sat, 14 Jan 2012 16:16:42 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q0EGGgw6029508; Sat, 14 Jan 2012 16:16:42 GMT (envelope-from nobody) Message-Id: <201201141616.q0EGGgw6029508@red.freebsd.org> Date: Sat, 14 Jan 2012 16:16:42 GMT From: "Guy M. Broome" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: sparc64/164123: Kernel fails to boot on Sun Ultra 5 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 16:20:13 -0000 >Number: 164123 >Category: sparc64 >Synopsis: Kernel fails to boot on Sun Ultra 5 >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-sparc64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Jan 14 16:20:12 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Guy M. Broome >Release: 9.0-RELEASE >Organization: Virginia Commonwealth University >Environment: FreeBSD yeoldesun4u.local1707.net 9.0-RC1 FreeBSD 9.0-RC1 #0: Sat Oct 22 23:56:51 EDT 2011 gmbroome@YeOldeSun4u.local1707.net:/usr/obj/usr/src/sys/MJOLNIR sparc64 >Description: I have a Sun Ultra 5 in use as a low-capacity data server. This unit has been running 9.0-RC1 with a custom kernel quite nicely since RC1 became available. This unit is able to boot RC1 custom and GENERIC kernels with no problem. In an attempt to upgrade to 9.0-RELEASE, I downloaded the kernel tarball via FTP, and unpacked it to the usual place, making sure to keep the RC1 kernel as kernel.old However, upon a reboot, the boot loader loads the 9.0-RELEASE GENERIC kernel, but immediately after "jumping to kernel entry", errors back to firmware with the message "Fast data access MMU miss". I've attempted to boot the 9.0-RELEASE GENERIC kernel, and a build from source using my custom config from RC1. Both fail with the MMU miss error. For good measure, I even tried using /boot/loader from 9.0-RELEASE. No go. The error is consistent every time a 9.0-RELEASE kernel is tried. RC1 still boots and runs normally. Unit contains: - 256MB RAM, factory original - 8.0GB IDE HD containing root partition on primary master channel - 80GB IDE HD containing /usr, on secondary master - CD-RW drive, on secondary slave - 400MHz UltraSPARC IIi dmesg from successfully-booting RC1 custom kernel: http://pastebin.com/N3NVfumc >How-To-Repeat: Attempt to boot 9.0-RELEASE (sparc64) kernel GENERIC on a Sun Ultra 5 >Fix: >Release-Note: >Audit-Trail: >Unformatted: