From owner-freebsd-sparc64@FreeBSD.ORG Mon Oct 10 11:07:17 2011 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 0F40C106567C for ; Mon, 10 Oct 2011 11:07:17 +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 F21A38FC23 for ; Mon, 10 Oct 2011 11:07:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9AB7GgD032513 for ; Mon, 10 Oct 2011 11:07:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9AB7GJ3032511 for freebsd-sparc64@FreeBSD.org; Mon, 10 Oct 2011 11:07:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Oct 2011 11:07:16 GMT Message-Id: <201110101107.p9AB7GJ3032511@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, 10 Oct 2011 11:07:17 -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 -------------------------------------------------------------------------------- f sparc/145211 sparc64 [panic] Memory modified after free o sparc/142102 sparc64 [nfs] [panic] FreeBSD 8.0 kernel panics on sparc64 whe o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 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/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 10 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Tue Oct 11 05:25:29 2011 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 C6968106566C for ; Tue, 11 Oct 2011 05:25:29 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 507138FC12 for ; Tue, 11 Oct 2011 05:25:28 +0000 (UTC) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p9B35dSH027206 for ; Tue, 11 Oct 2011 14:05:39 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p9B35VZF013972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2011 14:05:32 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id p9B35UHK004997; Tue, 11 Oct 2011 14:05:30 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id p9B35TMG004996; Tue, 11 Oct 2011 14:05:29 +1100 (EST) (envelope-from peter) Date: Tue, 11 Oct 2011 14:05:29 +1100 From: Peter Jeremy To: Marius Strobl Message-ID: <20111011030529.GA4093@server.vk2pj.dyndns.org> References: <20110601231237.GA5267@server.vk2pj.dyndns.org> <20110608224801.GB35494@alchemy.franken.de> <20110613235144.GA12470@server.vk2pj.dyndns.org> <20110813143807.GY48988@alchemy.franken.de> <20110816214820.GA35017@server.vk2pj.dyndns.org> <20110817094541.GJ48988@alchemy.franken.de> <20110830152725.GA28552@alchemy.franken.de> <20110831212458.GA25926@server.vk2pj.dyndns.org> <20110902153206.GR40781@alchemy.franken.de> <20111006120411.GA903@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <20111006120411.GA903@alchemy.franken.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org Subject: Re: 'make -j16 universe' gives SIReset 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, 11 Oct 2011 05:25:30 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Oct-06 14:04:11 +0200, Marius Strobl wr= ote: >FYI, as of r226057 I made sparc64 compatible with SCHED_ULE and vice versa >as requested. It would be great if you could test SCHED_ULE with buildworl= ds >your V890. Thank you for that. I've updated my V890 to r226167 and done some -j20 buildworlds with both SCHED_4BSD and SCHED_ULE immediately after rebooting. Raw time(1) results are: SCHED_4BSD: 16090.866u 9405.784s 51:18.57 828.1% 4514+1841k 31780+5809io 13927pf+0w 16061.213u 9530.148s 50:02.60 852.3% 4493+1837k 2970+5844io 12101pf+0w 16044.606u 9527.613s 50:08.29 850.0% 4493+1837k 3016+5840io 12082pf+0w 16073.767u 9514.049s 50:05.28 851.4% 4496+1838k 2955+5822io 12081pf+0w SCHED_ULE: 15160.032u 8739.799s 50:03.55 795.7% 4540+1848k 30162+4604io 13920pf+0w 15196.869u 8753.567s 48:49.01 817.6% 4537+1849k 2988+5891io 12094pf+0w 15193.226u 8726.949s 49:02.73 812.8% 4541+1850k 3031+5990io 12083pf+0w 15194.957u 8753.260s 49:03.19 813.6% 4537+1849k 2965+6028io 12082pf+0w 15167.735u 8744.979s 48:55.28 814.6% 4538+1849k 2964+6011io 12081pf+0w 15170.366u 8737.994s 49:01.01 812.9% 4537+1849k 2977+5930io 12081pf+0w Ignoring the first buildworld in both cases (when the caches were cold), ministat shows that ULE is faster (which I would expect): User time: x buildtimes.4BSD + buildtimes.ULE +----------------------------------------------------------------------+ | + | |+ + | |+ + xxx| ||AM |A|| +----------------------------------------------------------------------+ N Min Max Median Avg Stddev x 3 16044.606 16073.767 16061.213 16059.862 14.627368 + 5 15167.735 15196.869 15193.226 15184.631 14.311132 Difference at 95.0% confidence -875.231 +/- 25.7643 -5.44981% +/- 0.160426% (Student's t, pooled s =3D 14.4173) System time: x buildtimes.4BSD + buildtimes.ULE +----------------------------------------------------------------------+ | + | | + x| |+++ x x| ||AM AM| +----------------------------------------------------------------------+ N Min Max Median Avg Stddev x 3 9514.049 9530.148 9527.613 9523.9367 8.6562706 + 5 8726.949 8753.567 8744.979 8743.3498 11.213032 Difference at 95.0% confidence -780.587 +/- 18.6399 -8.19605% +/- 0.195717% (Student's t, pooled s =3D 10.4306) Wallclock time: x buildtimes.4BSD + buildtimes.ULE +----------------------------------------------------------------------+ | + | |+ + + + x x x| | |____A_M__| |_A__|| +----------------------------------------------------------------------+ N Min Max Median Avg Stddev x 3 3002.6 3008.29 3005.28 3005.39 2.8465945 + 5 2929.01 2943.19 2941.01 2938.244 6.0475185 Difference at 95.0% confidence -67.146 +/- 9.29992 -2.23419% +/- 0.309441% (Student's t, pooled s =3D 5.2041) I also ran 6 parallel -j16 buildworlds as a stress test and that was less successful: panic: mutex vm object not owned at /usr/src/sys/vm/vm_object.c:281 VNASSERT failed VNASSERT failed 0xfffff8a3467cdc20: VNASSERT failed tag ufs, type VDIR 0xfffff8a3467cdc20: 0xfffff8a3467cdc20: usecount 7, writecount 0, refco= unt 1 0 mountedhere 0 tag ufs, type VDIR flags () VNASSERT failed cpuid =3D 13 VNASSERT failed KDB: enter: panic tag ufs, type VDIR [ thread pid 1299 tid 100640 ] Stopped at kdb_enter+0x80: ta %xcc, 1 db> KDB: stack backtrace: KDB: stack backtrace: mi_switch() at mi_switch+0x1a8 sched_preempt() at sched_preempt+0xbc cpu_ipi_preempt() at cpu_ipi_preempt+0x4 -- interrupt level=3D0x6 pil=3D0x5 %o7=3D0xc085f414 -- cpu_ipi_stop() at cpu_ipi_stop+0x110 -- interrupt level=3D0x5 pil=3D0 %o7=3D0x3d280c -- userland() at 0x3d2458 user trace: trap %o7=3D0x3d280c pc 0x3d2458, sp 0x7fdffffccd1 pc 0x179724, sp 0x7fdffffcda1 pc 0x179b38, sp 0x7fdffffce61 pc 0x179c64, sp 0x7fdffffcf21 pc 0x179c84, sp 0x7fdffffcfe1 pc 0x415af0, sp 0x7fdffffd0a1 pc 0x143fe0, sp 0x7fdffffd161 pc 0x164c58, sp 0x7fdffffd221 pc 0x165840, sp 0x7fdffffd2e1 pc 0x148670, sp 0x7fdffffd3a1 pc 0x1a0c30, sp 0x7fdffffd471 pc 0x1001d0, sp 0x7fdffffd531 pc 0, sp 0x7fdffffd5f1 done KDB: stack backtrace: KDB: stack backtrace: mi_switch() at mi_switch+0x1a8 sched_preempt() at sched_preempt+0xbc cpu_ipi_preempt() at cpu_ipi_preempt+0x4 -- interrupt level=3D0x6 pil=3D0x5 %o7=3D0xc085f414 -- cpu_ipi_stop() at cpu_ipi_stop+0x110 -- interrupt level=3D0x5 pil=3D0 %o7=3D0xc04ec15c -- _mtx_lock_spin() at _mtx_lock_spin+0xb4 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x1b8 cnputs() at cnputs+0x5c vprintf() at vprintf+0x9c printf() at printf+0x20 vn_printf() at vn_printf+0x60 _vn_lock() at _vn_lock+0x2c cache_lookup() at cache_lookup+0x9a4 vfs_cache_lookup() at vfs_cache_lookup+0xbc VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x110 lookup() at lookup+0x7e0 namei() at namei+0x6c0 vn_open_cred() at vn_open_cred+0x31c vn_open() at vn_open+0x1c kern_openat() at kern_openat+0x1a4 kern_open() at kern_open+0x18 sys_open() at sys_open+0x14 syscall() at syscall+0x2d8 -- syscall (5, FreeBSD ELF64, sys_open) %o7=3D0x49fb98 -- userland() at 0x4e6bc8 user trace: trap %o7=3D0x49fb98 pc 0x4e6bc8, sp 0x7fdffffca81 pc 0x4a11a8, sp 0x7fdffffcb41 pc 0x4a15f4, sp 0x7fdffffcc81 pc 0x4a5904, sp 0x7fdffffcd41 pc 0x4a6930, sp 0x7fdffffce11 pc 0x49ebb0, sp 0x7fdffffced1 pc 0x49a4f4, sp 0x7fdffffcf91 pc 0x14fbf8, sp 0x7fdffffd0b1 pc 0x101160, sp 0x7fdffffd1f1 pc 0x10ecf8, sp 0x7fdffffd2b1 pc 0x1144c4, sp 0x7fdffffd3c1 pc 0x1a05a8, sp 0x7fdffffd481 pc 0x1001d0, sp 0x7fdffffd541 pc 0, sp 0x7fdffffd601 done KDB: stack backtrace: KDB: stack backtrace: mi_switch() at mi_switch+0x1a8 sched_preempt() at sched_preempt+0xbc cpu_ipi_preempt() at cpu_ipi_preempt+0x4 -- interrupt level=3D0x6 pil=3D0x5 %o7=3D0xc085f414 -- cpu_ipi_stop() at cpu_ipi_stop+0x110 -- interrupt level=3D0x5 pil=3D0 %o7=3D0xc04ec15c -- _mtx_lock_spin() at _mtx_lock_spin+0x70 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x1b8 cnputs() at cnputs+0x5c vprintf() at vprintf+0x9c printf() at printf+0x20 vn_printf() at vn_printf+0x60 _vn_lock() at _vn_lock+0x2c cache_lookup() at cache_lookup+0x9a4 vfs_cache_lookup() at vfs_cache_lookup+0xbc VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x110 lookup() at lookup+0x7e0 namei() at namei+0x6c0 vn_open_cred() at vn_open_cred+0x31c vn_open() at vn_open+0x1c kern_openat() at kern_openat+0x1a4 kern_open() at kern_open+0x18 sys_open() at sys_open+0x14 syscall() at syscall+0x2d8 -- syscall (5, FreeBSD ELF64, sys_open) %o7=3D0x49fb98 -- userland() at 0x4e6bc8 user trace: trap %o7=3D0x49fb98 pc 0x4e6bc8, sp 0x7fdffffc4f1 pc 0x4a11a8, sp 0x7fdffffc5b1 pc 0x4a15f4, sp 0x7fdffffc6f1 pc 0x4a5904, sp 0x7fdffffc7b1 pc 0x4a6930, sp 0x7fdffffc881 pc 0x49ebb0, sp 0x7fdffffc941 pc 0x49a4f4, sp 0x7fdffffca01 pc 0x14fbf8, sp 0x7fdffffcb21 pc 0x101160, sp 0x7fdffffcc61 pc 0x10ecf8, sp 0x7fdffffcd21 pc 0x1144c4, sp 0x7fdffffce31 pc 0x1a05a8, sp 0x7fdffffcef1 pc 0x1001d0, sp 0x7fdffffcfb1 pc 0, sp 0x7fdffffd071 done KDB: stack backtrace: KDB: stack backtrace: mi_switch() at mi_switch+0x1a8 sched_preempt() at sched_preempt+0xac cpu_ipi_preempt() at cpu_ipi_preempt+0x4 -- interrupt level=3D0x6 pil=3D0x5 %o7=3D0xc085f414 -- cpu_ipi_stop() at cpu_ipi_stop+0x114 -- interrupt level=3D0x5 pil=3D0 %o7=3D0xc085bb84 -- spinlock_exit() at spinlock_exit+0x28 _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0x16c sched_idletd() at sched_idletd+0x258 fork_exit() at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 db>=20 I haven't looked into this further. --=20 Peter Jeremy --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEUEARECAAYFAk6TsnkACgkQ/opHv/APuIfI9QCgvO46uFesW+Iu3dNpsyIG2ifl aUgAmJezL60GhFrnfhhNgr5n2CjiBR0= =Q4WE -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-sparc64@FreeBSD.ORG Tue Oct 11 20:55:49 2011 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 80FA0106564A for ; Tue, 11 Oct 2011 20:55:49 +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 07FFB8FC13 for ; Tue, 11 Oct 2011 20:55:48 +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 p9BKthmL033219; Tue, 11 Oct 2011 22:55:43 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9BKthRc033218; Tue, 11 Oct 2011 22:55:43 +0200 (CEST) (envelope-from marius) Date: Tue, 11 Oct 2011 22:55:43 +0200 From: Marius Strobl To: Peter Jeremy Message-ID: <20111011205543.GA81376@alchemy.franken.de> References: <20110608224801.GB35494@alchemy.franken.de> <20110613235144.GA12470@server.vk2pj.dyndns.org> <20110813143807.GY48988@alchemy.franken.de> <20110816214820.GA35017@server.vk2pj.dyndns.org> <20110817094541.GJ48988@alchemy.franken.de> <20110830152725.GA28552@alchemy.franken.de> <20110831212458.GA25926@server.vk2pj.dyndns.org> <20110902153206.GR40781@alchemy.franken.de> <20111006120411.GA903@alchemy.franken.de> <20111011030529.GA4093@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111011030529.GA4093@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: 'make -j16 universe' gives SIReset 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, 11 Oct 2011 20:55:49 -0000 On Tue, Oct 11, 2011 at 02:05:29PM +1100, Peter Jeremy wrote: > On 2011-Oct-06 14:04:11 +0200, Marius Strobl wrote: > >FYI, as of r226057 I made sparc64 compatible with SCHED_ULE and vice versa > >as requested. It would be great if you could test SCHED_ULE with buildworlds > >your V890. > > Thank you for that. I've updated my V890 to r226167 and done some > -j20 buildworlds with both SCHED_4BSD and SCHED_ULE immediately after > rebooting. Raw time(1) results are: > > SCHED_4BSD: > 16090.866u 9405.784s 51:18.57 828.1% 4514+1841k 31780+5809io 13927pf+0w > 16061.213u 9530.148s 50:02.60 852.3% 4493+1837k 2970+5844io 12101pf+0w > 16044.606u 9527.613s 50:08.29 850.0% 4493+1837k 3016+5840io 12082pf+0w > 16073.767u 9514.049s 50:05.28 851.4% 4496+1838k 2955+5822io 12081pf+0w > > SCHED_ULE: > 15160.032u 8739.799s 50:03.55 795.7% 4540+1848k 30162+4604io 13920pf+0w > 15196.869u 8753.567s 48:49.01 817.6% 4537+1849k 2988+5891io 12094pf+0w > 15193.226u 8726.949s 49:02.73 812.8% 4541+1850k 3031+5990io 12083pf+0w > 15194.957u 8753.260s 49:03.19 813.6% 4537+1849k 2965+6028io 12082pf+0w > 15167.735u 8744.979s 48:55.28 814.6% 4538+1849k 2964+6011io 12081pf+0w > 15170.366u 8737.994s 49:01.01 812.9% 4537+1849k 2977+5930io 12081pf+0w > > Ignoring the first buildworld in both cases (when the caches were cold), > ministat shows that ULE is faster (which I would expect): Well, in my tests 4BSD performed better than ULE but I only have 2-way and one 4-way machines and it's clear from the contention of the global 4BSD sched_lock alone that there must be some point where ULE scales better. So the real question is does the average sparc64 user have more than that number of cores in a machine (probably not)? On the other hand in my tests ULE+the atomic operation improvements roughly performed the same as 4BSD without these optimizations so there at least would be no net performance regression when switching to ULE now. > User time: > x buildtimes.4BSD > + buildtimes.ULE > +----------------------------------------------------------------------+ > | + | > |+ + | > |+ + xxx| > ||AM |A|| > +----------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 3 16044.606 16073.767 16061.213 16059.862 14.627368 > + 5 15167.735 15196.869 15193.226 15184.631 14.311132 > Difference at 95.0% confidence > -875.231 +/- 25.7643 > -5.44981% +/- 0.160426% > (Student's t, pooled s = 14.4173) > > System time: > x buildtimes.4BSD > + buildtimes.ULE > +----------------------------------------------------------------------+ > | + | > | + x| > |+++ x x| > ||AM AM| > +----------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 3 9514.049 9530.148 9527.613 9523.9367 8.6562706 > + 5 8726.949 8753.567 8744.979 8743.3498 11.213032 > Difference at 95.0% confidence > -780.587 +/- 18.6399 > -8.19605% +/- 0.195717% > (Student's t, pooled s = 10.4306) > Wallclock time: > x buildtimes.4BSD > + buildtimes.ULE > +----------------------------------------------------------------------+ > | + | > |+ + + + x x x| > | |____A_M__| |_A__|| > +----------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 3 3002.6 3008.29 3005.28 3005.39 2.8465945 > + 5 2929.01 2943.19 2941.01 2938.244 6.0475185 > Difference at 95.0% confidence > -67.146 +/- 9.29992 > -2.23419% +/- 0.309441% > (Student's t, pooled s = 5.2041) > > > I also ran 6 parallel -j16 buildworlds as a stress test and that was > less successful: > panic: mutex vm object not owned at /usr/src/sys/vm/vm_object.c:281 That line should be in vm_object_clear_flag(). The backtrace seems to be incomplete as it doesn't include that function. I'm not sure what to make out of the "VNASSERT failed" and "tag ufs, type VDIR" lines. I guess this could mean that there were two panics at the same time. Does the crashdump provide a better backtrace? > VNASSERT failed > VNASSERT failed > 0xfffff8a3467cdc20: VNASSERT failed > tag ufs, type VDIR > 0xfffff8a3467cdc20: 0xfffff8a3467cdc20: usecount 7, writecount 0, refcount 1 > 0 mountedhere 0 > tag ufs, type VDIR > flags () > VNASSERT failed > cpuid = 13 > VNASSERT failed > KDB: enter: panic > tag ufs, type VDIR > [ thread pid 1299 tid 100640 ] > Stopped at kdb_enter+0x80: ta %xcc, 1 > db> KDB: stack backtrace: > KDB: stack backtrace: > mi_switch() at mi_switch+0x1a8 > sched_preempt() at sched_preempt+0xbc > cpu_ipi_preempt() at cpu_ipi_preempt+0x4 > -- interrupt level=0x6 pil=0x5 %o7=0xc085f414 -- > cpu_ipi_stop() at cpu_ipi_stop+0x110 > -- interrupt level=0x5 pil=0 %o7=0x3d280c -- > userland() at 0x3d2458 > user trace: trap %o7=0x3d280c > pc 0x3d2458, sp 0x7fdffffccd1 > pc 0x179724, sp 0x7fdffffcda1 > pc 0x179b38, sp 0x7fdffffce61 > pc 0x179c64, sp 0x7fdffffcf21 > pc 0x179c84, sp 0x7fdffffcfe1 > pc 0x415af0, sp 0x7fdffffd0a1 > pc 0x143fe0, sp 0x7fdffffd161 > pc 0x164c58, sp 0x7fdffffd221 > pc 0x165840, sp 0x7fdffffd2e1 > pc 0x148670, sp 0x7fdffffd3a1 > pc 0x1a0c30, sp 0x7fdffffd471 > pc 0x1001d0, sp 0x7fdffffd531 > pc 0, sp 0x7fdffffd5f1 > done > KDB: stack backtrace: > KDB: stack backtrace: > mi_switch() at mi_switch+0x1a8 > sched_preempt() at sched_preempt+0xbc > cpu_ipi_preempt() at cpu_ipi_preempt+0x4 > -- interrupt level=0x6 pil=0x5 %o7=0xc085f414 -- > cpu_ipi_stop() at cpu_ipi_stop+0x110 > -- interrupt level=0x5 pil=0 %o7=0xc04ec15c -- > _mtx_lock_spin() at _mtx_lock_spin+0xb4 > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x1b8 > cnputs() at cnputs+0x5c > vprintf() at vprintf+0x9c > printf() at printf+0x20 > vn_printf() at vn_printf+0x60 > _vn_lock() at _vn_lock+0x2c > cache_lookup() at cache_lookup+0x9a4 > vfs_cache_lookup() at vfs_cache_lookup+0xbc > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x110 > lookup() at lookup+0x7e0 > namei() at namei+0x6c0 > vn_open_cred() at vn_open_cred+0x31c > vn_open() at vn_open+0x1c > kern_openat() at kern_openat+0x1a4 > kern_open() at kern_open+0x18 > sys_open() at sys_open+0x14 > syscall() at syscall+0x2d8 > -- syscall (5, FreeBSD ELF64, sys_open) %o7=0x49fb98 -- > userland() at 0x4e6bc8 > user trace: trap %o7=0x49fb98 > pc 0x4e6bc8, sp 0x7fdffffca81 > pc 0x4a11a8, sp 0x7fdffffcb41 > pc 0x4a15f4, sp 0x7fdffffcc81 > pc 0x4a5904, sp 0x7fdffffcd41 > pc 0x4a6930, sp 0x7fdffffce11 > pc 0x49ebb0, sp 0x7fdffffced1 > pc 0x49a4f4, sp 0x7fdffffcf91 > pc 0x14fbf8, sp 0x7fdffffd0b1 > pc 0x101160, sp 0x7fdffffd1f1 > pc 0x10ecf8, sp 0x7fdffffd2b1 > pc 0x1144c4, sp 0x7fdffffd3c1 > pc 0x1a05a8, sp 0x7fdffffd481 > pc 0x1001d0, sp 0x7fdffffd541 > pc 0, sp 0x7fdffffd601 > done > KDB: stack backtrace: > KDB: stack backtrace: > mi_switch() at mi_switch+0x1a8 > sched_preempt() at sched_preempt+0xbc > cpu_ipi_preempt() at cpu_ipi_preempt+0x4 > -- interrupt level=0x6 pil=0x5 %o7=0xc085f414 -- > cpu_ipi_stop() at cpu_ipi_stop+0x110 > -- interrupt level=0x5 pil=0 %o7=0xc04ec15c -- > _mtx_lock_spin() at _mtx_lock_spin+0x70 > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x1b8 > cnputs() at cnputs+0x5c > vprintf() at vprintf+0x9c > printf() at printf+0x20 > vn_printf() at vn_printf+0x60 > _vn_lock() at _vn_lock+0x2c > cache_lookup() at cache_lookup+0x9a4 > vfs_cache_lookup() at vfs_cache_lookup+0xbc > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x110 > lookup() at lookup+0x7e0 > namei() at namei+0x6c0 > vn_open_cred() at vn_open_cred+0x31c > vn_open() at vn_open+0x1c > kern_openat() at kern_openat+0x1a4 > kern_open() at kern_open+0x18 > sys_open() at sys_open+0x14 > syscall() at syscall+0x2d8 > -- syscall (5, FreeBSD ELF64, sys_open) %o7=0x49fb98 -- > userland() at 0x4e6bc8 > user trace: trap %o7=0x49fb98 > pc 0x4e6bc8, sp 0x7fdffffc4f1 > pc 0x4a11a8, sp 0x7fdffffc5b1 > pc 0x4a15f4, sp 0x7fdffffc6f1 > pc 0x4a5904, sp 0x7fdffffc7b1 > pc 0x4a6930, sp 0x7fdffffc881 > pc 0x49ebb0, sp 0x7fdffffc941 > pc 0x49a4f4, sp 0x7fdffffca01 > pc 0x14fbf8, sp 0x7fdffffcb21 > pc 0x101160, sp 0x7fdffffcc61 > pc 0x10ecf8, sp 0x7fdffffcd21 > pc 0x1144c4, sp 0x7fdffffce31 > pc 0x1a05a8, sp 0x7fdffffcef1 > pc 0x1001d0, sp 0x7fdffffcfb1 > pc 0, sp 0x7fdffffd071 > done > KDB: stack backtrace: > KDB: stack backtrace: > mi_switch() at mi_switch+0x1a8 > sched_preempt() at sched_preempt+0xac > cpu_ipi_preempt() at cpu_ipi_preempt+0x4 > -- interrupt level=0x6 pil=0x5 %o7=0xc085f414 -- > cpu_ipi_stop() at cpu_ipi_stop+0x114 > -- interrupt level=0x5 pil=0 %o7=0xc085bb84 -- > spinlock_exit() at spinlock_exit+0x28 > _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0x16c > sched_idletd() at sched_idletd+0x258 > fork_exit() at fork_exit+0x9c > fork_trampoline() at fork_trampoline+0x8 > > db> > > I haven't looked into this further. > > -- > Peter Jeremy From owner-freebsd-sparc64@FreeBSD.ORG Wed Oct 12 19:12:52 2011 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 02C201065670 for ; Wed, 12 Oct 2011 19:12:52 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.freebsd.org (Postfix) with ESMTP id 79E288FC12 for ; Wed, 12 Oct 2011 19:12:51 +0000 (UTC) Received: from charlemagne.boland.org (59-36-215.ftth.xms.internl.net [82.215.36.59]) (authenticated bits=0) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id p9CIw8k0076189 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 12 Oct 2011 20:58:08 +0200 (CEST) (envelope-from michiel@boland.org) Message-ID: <4E95E340.3060308@boland.org> Date: Wed, 12 Oct 2011 20:58:08 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.23) Gecko/20110930 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: netbooting 9.0-beta3 with serial console 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, 12 Oct 2011 19:12:52 -0000 Hi. How do I install 9.0-BETA3 on sparc64 via netbooting and a serial console? This used to work on previous releases simply by exporting the mounted cdrom over nfs, and having vfs.root.mountfrom="ufs:/dev/md0" in /tftpboot/boot/loader.conf.local But there is no longer an mfsroot on the dvd or bootonly images, so the boot fails with Trying to mount root from ufs:/dev/md0 []... mountroot: waiting for device /dev/md0 ... Mounting from ufs:/dev/md0 failed with error 19. the system will then continue booting: Trying to mount root from nfs: []... NFS ROOT: 192.168.61.11:/cdrom gem0: link state changed to DOWN gem0: link state changed to UP /etc/rc.initdiskless: cannot create /dev/null: Read-only file system ps: /dev/null: No such file or directory /etc/rc: cannot create /dev/null: Read-only file system /etc/rc: cannot create /dev/null: Read-only file system Wed Oct 12 17:52:39 UTC 2011 At this point though, there is no login prompt on the console, and I have to power-cycle. I suspect there is a prompt on ttyv0, but that's of no use if there is only a serial console and no monitor output. The 8.2-RELEASE loader/kernel would detect a serial console correctly. If I remove the /tftpboot/boot/loader.conf.local, the boot fails with [...] Trying to mount root from cd9660:/dev/iso9660/FreeBSD_Install [ro]... mountroot: waiting for device /dev/iso9660/FreeBSD_Install ... Mounting from cd9660:/dev/iso9660/FreeBSD_Install failed with error 19. Trying to mount root from nfs: []... NFS ROOT: 192.168.61.11:/cdrom gem0: link state changed to DOWN gem0: link state changed to UP Interface gem0 IP-Address 192.168.61.3 Broadcast 192.168.61.255 No suitable dump device was found. eval: cannot create /dev/null: Read-only file system eval: cannot create /dev/null: Read-only file system Entropy harvesting:. Starting file system checks: mount_nfs: no : 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 CD98A106564A for ; Wed, 12 Oct 2011 20:24:49 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id A20F58FC08 for ; Wed, 12 Oct 2011 20:24:49 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LSY00A00WLCGP00@smtpauth2.wiscmail.wisc.edu> for freebsd-sparc64@freebsd.org; Wed, 12 Oct 2011 14:24:48 -0500 (CDT) Received: from wanderer.tachypleus.net ([unknown] [128.104.255.9]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LSY00MG3WLBCM20@smtpauth2.wiscmail.wisc.edu>; Wed, 12 Oct 2011 14:24:47 -0500 (CDT) Date: Wed, 12 Oct 2011 14:24:47 -0500 From: Nathan Whitehorn In-reply-to: <4E95E340.3060308@boland.org> To: Michiel Boland Message-id: <4E95E97F.9040304@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.255.9 X-Spam-PmxInfo: Server=avs-13, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.10.12.191514, SenderIP=128.104.255.9 References: <4E95E340.3060308@boland.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20110928 Thunderbird/7.0 Cc: freebsd-sparc64@freebsd.org Subject: Re: netbooting 9.0-beta3 with serial console 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, 12 Oct 2011 20:24:49 -0000 On 10/12/11 13:58, Michiel Boland wrote: > Hi. How do I install 9.0-BETA3 on sparc64 via netbooting and a serial > console? > > This used to work on previous releases simply by exporting the mounted > cdrom over nfs, and having > vfs.root.mountfrom="ufs:/dev/md0" > in /tftpboot/boot/loader.conf.local > > But there is no longer an mfsroot on the dvd or bootonly images, so the > boot fails with > > Trying to mount root from ufs:/dev/md0 []... > mountroot: waiting for device /dev/md0 ... > Mounting from ufs:/dev/md0 failed with error 19. There's no longer a special root, so just netbooting in the regular way should work. > the system will then continue booting: > > Trying to mount root from nfs: []... > NFS ROOT: 192.168.61.11:/cdrom > gem0: link state changed to DOWN > gem0: link state changed to UP > /etc/rc.initdiskless: cannot create /dev/null: Read-only file system > ps: /dev/null: No such file or directory > /etc/rc: cannot create /dev/null: Read-only file system > /etc/rc: cannot create /dev/null: Read-only file system It looks like rc.diskless has failed you here, and somewhat broken devfs, so there's likely a bug there which should be looked into. If you just want to test the installer, you can make a netboot environment by doing: mkdir /path/to/nfs/export cd /path/to/nfs/export tar xvzf /cdrom/usr/freebsd-dist/*.txz cp /cdrom/etc/rc.local etc and then booting from there, which will be read-write. I'll try to find out what goes wrong when FreeBSD netboots from read-only media. -Nathan From owner-freebsd-sparc64@FreeBSD.ORG Thu Oct 13 03:56:58 2011 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 6B0701065673 for ; Thu, 13 Oct 2011 03:56:58 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.freebsd.org (Postfix) with ESMTP id EF37A8FC08 for ; Thu, 13 Oct 2011 03:56:57 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p9D3uoSH010758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Oct 2011 14:56:51 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id p9D3und7054270; Thu, 13 Oct 2011 14:56:49 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id p9D3um8t054269; Thu, 13 Oct 2011 14:56:48 +1100 (EST) (envelope-from peter) Date: Thu, 13 Oct 2011 14:56:48 +1100 From: Peter Jeremy To: Marius Strobl Message-ID: <20111013035648.GA54190@server.vk2pj.dyndns.org> References: <20110613235144.GA12470@server.vk2pj.dyndns.org> <20110813143807.GY48988@alchemy.franken.de> <20110816214820.GA35017@server.vk2pj.dyndns.org> <20110817094541.GJ48988@alchemy.franken.de> <20110830152725.GA28552@alchemy.franken.de> <20110831212458.GA25926@server.vk2pj.dyndns.org> <20110902153206.GR40781@alchemy.franken.de> <20111006120411.GA903@alchemy.franken.de> <20111011030529.GA4093@server.vk2pj.dyndns.org> <20111011205543.GA81376@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <20111011205543.GA81376@alchemy.franken.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-sparc64@freebsd.org Subject: Re: 'make -j16 universe' gives SIReset 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, 13 Oct 2011 03:56:58 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Oct-11 22:55:43 +0200, Marius Strobl wr= ote: >> I also ran 6 parallel -j16 buildworlds as a stress test and that was >> less successful: >> panic: mutex vm object not owned at /usr/src/sys/vm/vm_object.c:281 > >That line should be in vm_object_clear_flag(). The backtrace seems to be >incomplete as it doesn't include that function. I'm not sure what to make >out of the "VNASSERT failed" and "tag ufs, type VDIR" lines. I guess this >could mean that there were two panics at the same time. Does the crashdump >provide a better backtrace? Unfortunately, I can't get a crashdump because dumpon(8) doesn't like my Solaris swap partitions: GEOM_PART: Partition 'da0b' not suitable for kernel dumps (wrong type?) GEOM_PART: Partition 'da6b' not suitable for kernel dumps (wrong type?) No suitable dump device was found. I did write a patch for that but took it out during some earlier testing to get back to stock code. It looks like I didn't PR it either so I will do that when I get some time. I don't understand the panic backtrace either. Manually running "where" gives saner output: db> where Tracing pid 1299 tid 100640 td 0xfffff8a346e8da40 panic() at panic+0x20c _mtx_assert() at _mtx_assert+0xb0 vm_object_clear_flag() at vm_object_clear_flag+0x24 vmtotal() at vmtotal+0xa4 sysctl_root() at sysctl_root+0x234 userland_sysctl() at userland_sysctl+0x1cc sys___sysctl() at sys___sysctl+0x70 syscall() at syscall+0x2d8 -- syscall (202, FreeBSD ELF64, sys___sysctl) %o7=3D0x10daac -- userland() at 0x4093c3a8 user trace: trap %o7=3D0x10daac pc 0x4093c3a8, sp 0x7fdffffcdd1 pc 0x10dc58, sp 0x7fdffffcea1 pc 0x1050c0, sp 0x7fdffffcf71 pc 0x4089c6e0, sp 0x7fdffffd041 pc 0, sp 0x7fdffffd401 pc 0x403ab9a0, sp 0x7fdffffd561 pc 0x104980, sp 0x7fdffffd631 pc 0x105514, sp 0x7fdffffd751 pc 0x102790, sp 0x7fdffffe031 pc 0x4021b014, sp 0x7fdffffe0f1 done I'm not sure how to access registers in another stack frame so I can't find the offending vmobject. I will need to shutdown that box and will do some more digging next week. --=20 Peter Jeremy --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6WYYAACgkQ/opHv/APuIc2XwCfT9gnguzgFMIkDlXu3GKOIEy7 0RsAnjC5HJF0UHbQ6xBojQeMAF5eB3dZ =9G22 -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Oct 13 17:40:07 2011 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 549E9106566B for ; Thu, 13 Oct 2011 17:40:07 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.freebsd.org (Postfix) with ESMTP id D9F8D8FC08 for ; Thu, 13 Oct 2011 17:40:06 +0000 (UTC) Received: from charlemagne.boland.org (59-36-215.ftth.xms.internl.net [82.215.36.59]) (authenticated bits=0) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id p9DHdYtb024036 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 13 Oct 2011 19:39:34 +0200 (CEST) (envelope-from michiel@boland.org) Message-ID: <4E972256.5010809@boland.org> Date: Thu, 13 Oct 2011 19:39:34 +0200 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.23) Gecko/20110930 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org References: <4E95E340.3060308@boland.org> <4E95E97F.9040304@freebsd.org> In-Reply-To: <4E95E97F.9040304@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: netbooting 9.0-beta3 with serial console 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, 13 Oct 2011 17:40:07 -0000 On 10/12/2011 21:24, Nathan Whitehorn wrote: > On 10/12/11 13:58, Michiel Boland wrote: >> Hi. How do I install 9.0-BETA3 on sparc64 via netbooting and a serial >> console? [...] > It looks like rc.diskless has failed you here, and somewhat broken devfs, so > there's likely a bug there which should be looked into. If you just want to test > the installer, you can make a netboot environment by doing: > > mkdir /path/to/nfs/export > cd /path/to/nfs/export > tar xvzf /cdrom/usr/freebsd-dist/*.txz > cp /cdrom/etc/rc.local etc > > and then booting from there, which will be read-write. I'll try to find out what > goes wrong when FreeBSD netboots from read-only media. What happens is that /etc/rc.d/root fails because it cannot do 'mount -uw /' Then further down in the boot process, /etc/rc.d/mountcritlocal fails because it cannot find /dev/iso9660/FreeBSD_Install I worked around this by doing two things: add root_rw_mount="NO" to /etc/rc.conf and truncate /etc/fstab Netbooting then continues into the installer. Cheers Michiel From owner-freebsd-sparc64@FreeBSD.ORG Thu Oct 13 18:42:29 2011 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 C03A4106566C for ; Thu, 13 Oct 2011 18:42:29 +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 566E08FC1C for ; Thu, 13 Oct 2011 18:42:28 +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 p9DIgPOW049099; Thu, 13 Oct 2011 20:42:25 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9DIgPxK049098; Thu, 13 Oct 2011 20:42:25 +0200 (CEST) (envelope-from marius) Date: Thu, 13 Oct 2011 20:42:25 +0200 From: Marius Strobl To: Peter Jeremy Message-ID: <20111013184224.GG39118@alchemy.franken.de> References: <20110813143807.GY48988@alchemy.franken.de> <20110816214820.GA35017@server.vk2pj.dyndns.org> <20110817094541.GJ48988@alchemy.franken.de> <20110830152725.GA28552@alchemy.franken.de> <20110831212458.GA25926@server.vk2pj.dyndns.org> <20110902153206.GR40781@alchemy.franken.de> <20111006120411.GA903@alchemy.franken.de> <20111011030529.GA4093@server.vk2pj.dyndns.org> <20111011205543.GA81376@alchemy.franken.de> <20111013035648.GA54190@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111013035648.GA54190@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: 'make -j16 universe' gives SIReset 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, 13 Oct 2011 18:42:29 -0000 On Thu, Oct 13, 2011 at 02:56:48PM +1100, Peter Jeremy wrote: > On 2011-Oct-11 22:55:43 +0200, Marius Strobl wrote: > >> I also ran 6 parallel -j16 buildworlds as a stress test and that was > >> less successful: > >> panic: mutex vm object not owned at /usr/src/sys/vm/vm_object.c:281 > > > >That line should be in vm_object_clear_flag(). The backtrace seems to be > >incomplete as it doesn't include that function. I'm not sure what to make > >out of the "VNASSERT failed" and "tag ufs, type VDIR" lines. I guess this > >could mean that there were two panics at the same time. Does the crashdump > >provide a better backtrace? > > Unfortunately, I can't get a crashdump because dumpon(8) doesn't like > my Solaris swap partitions: > GEOM_PART: Partition 'da0b' not suitable for kernel dumps (wrong type?) > GEOM_PART: Partition 'da6b' not suitable for kernel dumps (wrong type?) > No suitable dump device was found. > > I did write a patch for that but took it out during some earlier > testing to get back to stock code. It looks like I didn't PR it > either so I will do that when I get some time. > > I don't understand the panic backtrace either. Manually running > "where" gives saner output: > db> where > Tracing pid 1299 tid 100640 td 0xfffff8a346e8da40 > panic() at panic+0x20c > _mtx_assert() at _mtx_assert+0xb0 > vm_object_clear_flag() at vm_object_clear_flag+0x24 > vmtotal() at vmtotal+0xa4 > sysctl_root() at sysctl_root+0x234 > userland_sysctl() at userland_sysctl+0x1cc > sys___sysctl() at sys___sysctl+0x70 > syscall() at syscall+0x2d8 > -- syscall (202, FreeBSD ELF64, sys___sysctl) %o7=0x10daac -- > userland() at 0x4093c3a8 > user trace: trap %o7=0x10daac > pc 0x4093c3a8, sp 0x7fdffffcdd1 > pc 0x10dc58, sp 0x7fdffffcea1 > pc 0x1050c0, sp 0x7fdffffcf71 > pc 0x4089c6e0, sp 0x7fdffffd041 > pc 0, sp 0x7fdffffd401 > pc 0x403ab9a0, sp 0x7fdffffd561 > pc 0x104980, sp 0x7fdffffd631 > pc 0x105514, sp 0x7fdffffd751 > pc 0x102790, sp 0x7fdffffe031 > pc 0x4021b014, sp 0x7fdffffe0f1 > done Hrm, this backtrace seems impossible as vmtotal() explicitly locks the object before calling vm_object_clear_flag(). A crash dump of this panic really would be interesting. > > I'm not sure how to access registers in another stack frame so I > can't find the offending vmobject. I will need to shutdown that > box and will do some more digging next week. > I don't think ddb(4) supports accessing registers of another frame, it however has some VM object debugging support you could play with if the machine is still running. Marius