From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 4 11:07:11 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 0E54D106566B for ; Mon, 4 Jul 2011 11:07:11 +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 F01CA8FC19 for ; Mon, 4 Jul 2011 11:07:10 +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 p64B7AJx040557 for ; Mon, 4 Jul 2011 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p64B7AXA040555 for freebsd-sparc64@FreeBSD.org; Mon, 4 Jul 2011 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Jul 2011 11:07:10 GMT Message-Id: <201107041107.p64B7AXA040555@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, 04 Jul 2011 11:07:11 -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 Mon Jul 4 14:34:23 2011 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 CB00A106564A; Mon, 4 Jul 2011 14:34:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3CA1E8FC0A; Mon, 4 Jul 2011 14:34:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64EYMYt021837; Mon, 4 Jul 2011 10:34:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64EYMjJ021830; Mon, 4 Jul 2011 14:34:22 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 14:34:22 GMT Message-Id: <201107041434.p64EYMjJ021830@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head 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, 04 Jul 2011 14:34:23 -0000 TB --- 2011-07-04 13:32:06 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 13:32:06 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-04 13:32:06 - cleaning the object tree TB --- 2011-07-04 13:32:21 - cvsupping the source tree TB --- 2011-07-04 13:32:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-04 13:32:34 - building world TB --- 2011-07-04 13:32:34 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 13:32:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 13:32:34 - TARGET=sparc64 TB --- 2011-07-04 13:32:34 - TARGET_ARCH=sparc64 TB --- 2011-07-04 13:32:34 - TZ=UTC TB --- 2011-07-04 13:32:34 - __MAKE_CONF=/dev/null TB --- 2011-07-04 13:32:34 - cd /src TB --- 2011-07-04 13:32:34 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 13:32:34 UTC 2011 >>> 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 Jul 4 14:31:32 UTC 2011 TB --- 2011-07-04 14:31:32 - generating LINT kernel config TB --- 2011-07-04 14:31:32 - cd /src/sys/sparc64/conf TB --- 2011-07-04 14:31:32 - /usr/bin/make -B LINT TB --- 2011-07-04 14:31:32 - building LINT kernel TB --- 2011-07-04 14:31:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 14:31:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 14:31:32 - TARGET=sparc64 TB --- 2011-07-04 14:31:32 - TARGET_ARCH=sparc64 TB --- 2011-07-04 14:31:32 - TZ=UTC TB --- 2011-07-04 14:31:32 - __MAKE_CONF=/dev/null TB --- 2011-07-04 14:31:32 - cd /src TB --- 2011-07-04 14:31:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 14:31:32 UTC 2011 >>> 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 -Wmissing-include-dirs -fdiagnostics-show-option -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 /src/sys/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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 -Wmissing-include-dirs -fdiagnostics-show-option -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 /src/sys/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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 -Wmissing-include-dirs -fdiagnostics-show-option -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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h: In function '_ng_node_unref': /src/sys/netgraph/netgraph.h:500: error: void value not ignored as it ought to be *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 14:34:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 14:34:22 - ERROR: failed to build lint kernel TB --- 2011-07-04 14:34:22 - 2887.96 user 715.31 system 3735.96 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 4 18:51:57 2011 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 C1A161065673; Mon, 4 Jul 2011 18:51:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 91E3D8FC08; Mon, 4 Jul 2011 18:51:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p64IpuNU010539; Mon, 4 Jul 2011 14:51:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p64Ipumh010538; Mon, 4 Jul 2011 18:51:56 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 4 Jul 2011 18:51:56 GMT Message-Id: <201107041851.p64Ipumh010538@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head 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, 04 Jul 2011 18:51:57 -0000 TB --- 2011-07-04 17:49:27 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-04 17:49:27 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-04 17:49:27 - cleaning the object tree TB --- 2011-07-04 17:49:38 - cvsupping the source tree TB --- 2011-07-04 17:49:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-04 17:50:22 - building world TB --- 2011-07-04 17:50:22 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 17:50:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 17:50:22 - TARGET=sparc64 TB --- 2011-07-04 17:50:22 - TARGET_ARCH=sparc64 TB --- 2011-07-04 17:50:22 - TZ=UTC TB --- 2011-07-04 17:50:22 - __MAKE_CONF=/dev/null TB --- 2011-07-04 17:50:22 - cd /src TB --- 2011-07-04 17:50:22 - /usr/bin/make -B buildworld >>> World build started on Mon Jul 4 17:50:23 UTC 2011 >>> 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 Jul 4 18:49:06 UTC 2011 TB --- 2011-07-04 18:49:06 - generating LINT kernel config TB --- 2011-07-04 18:49:06 - cd /src/sys/sparc64/conf TB --- 2011-07-04 18:49:06 - /usr/bin/make -B LINT TB --- 2011-07-04 18:49:06 - building LINT kernel TB --- 2011-07-04 18:49:06 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-04 18:49:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-04 18:49:06 - TARGET=sparc64 TB --- 2011-07-04 18:49:06 - TARGET_ARCH=sparc64 TB --- 2011-07-04 18:49:06 - TZ=UTC TB --- 2011-07-04 18:49:06 - __MAKE_CONF=/dev/null TB --- 2011-07-04 18:49:06 - cd /src TB --- 2011-07-04 18:49:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 4 18:49:06 UTC 2011 >>> 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 -Wmissing-include-dirs -fdiagnostics-show-option -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 /src/sys/contrib/ipfilter/netinet/ip_sync.c -I/src/sys/contrib/ipfilter 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 -Wmissing-include-dirs -fdiagnostics-show-option -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 /src/sys/contrib/ipfilter/netinet/mlfk_ipl.c -I/src/sys/contrib/ipfilter 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 -Wmissing-include-dirs -fdiagnostics-show-option -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 /src/sys/contrib/ngatm/netnatm/api/cc_conn.c -I/src/sys/contrib/ngatm In file included from /src/sys/netgraph/atm/ccatm/ng_ccatm_cust.h:43, from /src/sys/contrib/ngatm/netnatm/api/ccpriv.h:38, from /src/sys/contrib/ngatm/netnatm/api/cc_conn.c:47: /src/sys/netgraph/netgraph.h:498: error: conflicting types for '_ng_node_unref' /src/sys/netgraph/netgraph.h:445: error: previous declaration of '_ng_node_unref' was here *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-04 18:51:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-04 18:51:56 - ERROR: failed to build lint kernel TB --- 2011-07-04 18:51:56 - 2879.98 user 712.33 system 3749.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Mon Jul 4 21:42:08 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 77B32106564A; Mon, 4 Jul 2011 21:42:08 +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 EF8B08FC13; Mon, 4 Jul 2011 21:42:07 +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 p64LfwZ2073303; Mon, 4 Jul 2011 23:41:58 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p64LfwdK073302; Mon, 4 Jul 2011 23:41:58 +0200 (CEST) (envelope-from marius) Date: Mon, 4 Jul 2011 23:41:58 +0200 From: Marius Strobl To: Alan Cox Message-ID: <20110704214158.GX14797@alchemy.franken.de> References: <20110615233445.GZ7064@alchemy.franken.de> <20110619220033.GA61397@server.vk2pj.dyndns.org> <20110622100524.GO14797@alchemy.franken.de> <20110629025433.GA48145@server.vk2pj.dyndns.org> <20110629175444.GH14797@alchemy.franken.de> <20110629220010.GA53017@pjdesk.au.alcatel-lucent.com> <20110629223008.GL14797@alchemy.franken.de> <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> <20110702002325.GS14797@alchemy.franken.de> <4E0F6B8D.8000500@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0F6B8D.8000500@rice.edu> User-Agent: Mutt/1.4.2.3i Cc: Peter Jeremy , "alc@freebsd.org" , 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: Mon, 04 Jul 2011 21:42:08 -0000 On Sat, Jul 02, 2011 at 02:03:41PM -0500, Alan Cox wrote: > On 07/01/2011 19:23, Marius Strobl wrote: > >On Fri, Jul 01, 2011 at 08:17:52AM +1000, Peter Jeremy wrote: > >>[Moving back on-list] > >> > >>On 2011-Jun-30 06:30:08 +0800, Marius Strobl > >>wrote: > >>>On Thu, Jun 30, 2011 at 08:00:10AM +1000, Peter Jeremy wrote: > >>>>On 2011-Jun-29 19:54:44 +0200, Marius Strobl > >>>>wrote: > >>>>>On Wed, Jun 29, 2011 at 12:54:33PM +1000, Peter Jeremy wrote: > >>>>>>My V890 has been running "make -j32 buildworld" in a loop for a > >>>>>>week now without problems so I think that was the problem. > >>>>OTOH, a V440 that has been running similar load for a similar period > >>>>died overnight with: > >>>> > >>>>panic: uma_small_alloc: free page still has mappings! > >>>>VNASSERT failed > >>>>cpuid = 3 > >>>>0xfffff800079643c0: KDB: enter: panic > >>... > >>>>I'm fairly sure that is the same kernel but will double-check and > >>>>investigate that panic further. > >>FWIW, that kernel didn't have the latest patchset (adding Zeus support). > >That shouldn't make a difference; the later version only adds the > >SPARC64 bits as you already noticed and adjusts the boot loader to > >compile again. I made no changes to the existing parts apart from > >fixing a comment. Besides I see no connection between fixing the > >gross user TLB flushing and the below problem so far. > > > >>>Ok, this appears to be an unrelated problem though. Alan, do you > >>>have an idea what could be causing this? > >>I managed to get the same panic (though different traceback) on the > >>V890 after about an hour of pho@'s stress test with INCARNATIONS=150: > >> > >>panic: uma_small_alloc: free page still has mappings! > >>cpuid = 1 > >>KDB: enter: panic > >>[ thread pid 142 tid 100196 ] > >>Stopped at kdb_enter+0x80: ta %xcc, 1 > >>db> where > >>Tracing pid 142 tid 100196 td 0xfffff8a016ace880 > >>panic() at panic+0x20c > >>uma_small_alloc() at uma_small_alloc+0xe8 > >>keg_alloc_slab() at keg_alloc_slab+0xc8 > >>keg_fetch_slab() at keg_fetch_slab+0x218 > >>zone_fetch_slab() at zone_fetch_slab+0x44 > >>uma_zalloc_arg() at uma_zalloc_arg+0x60c > >>m_getm2() at m_getm2+0x134 > >>m_uiotombuf() at m_uiotombuf+0x4c > >>sosend_generic() at sosend_generic+0x420 > >>sosend() at sosend+0x2c > >>soo_write() at soo_write+0x3c > >>dofilewrite() at dofilewrite+0x7c > >>kern_writev() at kern_writev+0x38 > >>write() at write+0x4c > >>syscallenter() at syscallenter+0x270 > >>syscall() at syscall+0x74 > >>-- syscall (4, FreeBSD ELF64, write) %o7=0x101db4 -- > >>userland() at 0x405936c8 > >>user trace: trap %o7=0x101db4 > >>pc 0x405936c8, sp 0x7fdffffd8a1 > >>pc 0x101f44, sp 0x7fdffffd9a1 > >>pc 0x104604, sp 0x7fdffffda81 > >>pc 0x1046f0, sp 0x7fdffffdb51 > >>pc 0x104994, sp 0x7fdffffdc21 > >>pc 0x104d90, sp 0x7fdffffdd01 > >>pc 0x101610, sp 0x7fdffffde41 > >>pc 0x4020cff4, sp 0x7fdffffdf01 > >>done > >>db> > >> > >>I've got a crashdump on the V440 but discovered that gdb reports > >>"GDB can't read core files on this machine." so it isn't much use. > >>Any suggestions on how to debug this? > >The VM and its interaction with the MD code are beyond me, I hope > >Alan can chime in here. Reading through the code I see a possible > >path which could lead to this though; tsb_tte_enter(), which is > >the only place where TD_PV ever is set and also only in case of > >managed pages, always calls pmap_cache_enter(), which together > >with pmap_cache_remove() does the page color handling. In > >pmap_remove_all() however, pmap_cache_remove() is only called for > >managed pages, so for unmanaged pages we might miss the removal > >of the mapping from the the color used. I've no idea though if > >this actually is relevant, i.e. whether the VM ever calls > >pmap_remove_all() for unmanaged pages. > > In HEAD, it does not. Other architectures have an assertion forbidding > pmap_remove_all() calls on unmanaged pages. (Btw, I'm happy to add this > assertion to sparc64's pmap if you like.) In older versions, calling > pmap_remove_all() on unmanaged pages is expected to be a harmless NOP > that's just a waste of cycles. > > With unmanaged pages, it is expected that pmap_remove() is used to > destroy mappings before the page is freed. > > For years, vm_page_free{,_toq}() has asserted that the page has no > managed mappings: > > if ((m->flags & PG_UNMANAGED) == 0) { > vm_page_lock_assert(m, MA_OWNED); > KASSERT(!pmap_page_is_mapped(m), > ("vm_page_free_toq: freeing mapped page %p", m)); > } > Okay, then my theories don't hold. > As a debugging aid, you might want to add an additional check here on > colors. I did that and it turns out to trigger rather quickly: Trying to mount root from nfs: []... NFS ROOT: 192.168.1.40:/usr/data/nfsroot/sparc64 dc1: link state changed to UP panic: vm_page_free_toq: free page 0xfffff80047b8a088 still has mappings! cpuid = 0 KDB: enter: panic [ thread pid 1 tid 100001 ] Stopped at kdb_enter+0x80: ta %xcc, 1 db> bt Tracing pid 1 tid 100001 td 0xfffff80041094000 panic() at panic+0x20c vm_page_free_toq() at vm_page_free_toq+0xb4 vm_page_free_zero() at vm_page_free_zero+0x10 pmap_release() at pmap_release+0x170 vmspace_free() at vmspace_free+0x70 vmspace_exec() at vmspace_exec+0x48 exec_new_vmspace() at exec_new_vmspace+0x240 exec_elf64_imgact() at exec_elf64_imgact+0x598 kern_execve() at kern_execve+0x398 execve() at execve+0x34 start_init() at start_init+0x2ec fork_exit() at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 db> Further debugging shows that the page in question is one of the TSB pages entered by pmap_pinit(). In pmap_release() vm_page_free_zero() is called on these before pmap_qremove(), so there appears to be a race in which these pages can get re-used before their mappings are removed. I suspect that this might be related to your change in r207648, but just reverting that one nowadays this triggers the assertion in vm_page_free_toq() about the page lock not being held. Anyway, I'm not sure what the right fix for this is; should pmap_release() call pmap_qremove() on these pages one-by-one before calling vm_page_free_zero() or maybe just call pmap_qremove() for all of them before looping over them and calling vm_page_free_zero()? Marius From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 5 16:07:15 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 9D71B106566B; Tue, 5 Jul 2011 16:07:15 +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 07A688FC13; Tue, 5 Jul 2011 16:07:14 +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 p65G79Yq077912; Tue, 5 Jul 2011 18:07:10 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p65G79CL077911; Tue, 5 Jul 2011 18:07:09 +0200 (CEST) (envelope-from marius) Date: Tue, 5 Jul 2011 18:07:09 +0200 From: Marius Strobl To: Alan Cox Message-ID: <20110705160709.GA77843@alchemy.franken.de> References: <20110619220033.GA61397@server.vk2pj.dyndns.org> <20110622100524.GO14797@alchemy.franken.de> <20110629025433.GA48145@server.vk2pj.dyndns.org> <20110629175444.GH14797@alchemy.franken.de> <20110629220010.GA53017@pjdesk.au.alcatel-lucent.com> <20110629223008.GL14797@alchemy.franken.de> <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> <20110702002325.GS14797@alchemy.franken.de> <4E0F6B8D.8000500@rice.edu> <20110704214158.GX14797@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110704214158.GX14797@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: Peter Jeremy , "alc@freebsd.org" , 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, 05 Jul 2011 16:07:15 -0000 On Mon, Jul 04, 2011 at 11:41:58PM +0200, Marius Strobl wrote: > On Sat, Jul 02, 2011 at 02:03:41PM -0500, Alan Cox wrote: > > On 07/01/2011 19:23, Marius Strobl wrote: > > >On Fri, Jul 01, 2011 at 08:17:52AM +1000, Peter Jeremy wrote: > > >>[Moving back on-list] > > >> > > >>On 2011-Jun-30 06:30:08 +0800, Marius Strobl > > >>wrote: > > >>>On Thu, Jun 30, 2011 at 08:00:10AM +1000, Peter Jeremy wrote: > > >>>>On 2011-Jun-29 19:54:44 +0200, Marius Strobl > > >>>>wrote: > > >>>>>On Wed, Jun 29, 2011 at 12:54:33PM +1000, Peter Jeremy wrote: > > >>>>>>My V890 has been running "make -j32 buildworld" in a loop for a > > >>>>>>week now without problems so I think that was the problem. > > >>>>OTOH, a V440 that has been running similar load for a similar period > > >>>>died overnight with: > > >>>> > > >>>>panic: uma_small_alloc: free page still has mappings! > > >>>>VNASSERT failed > > >>>>cpuid = 3 > > >>>>0xfffff800079643c0: KDB: enter: panic > > >>... > > >>>>I'm fairly sure that is the same kernel but will double-check and > > >>>>investigate that panic further. > > >>FWIW, that kernel didn't have the latest patchset (adding Zeus support). > > >That shouldn't make a difference; the later version only adds the > > >SPARC64 bits as you already noticed and adjusts the boot loader to > > >compile again. I made no changes to the existing parts apart from > > >fixing a comment. Besides I see no connection between fixing the > > >gross user TLB flushing and the below problem so far. > > > > > >>>Ok, this appears to be an unrelated problem though. Alan, do you > > >>>have an idea what could be causing this? > > >>I managed to get the same panic (though different traceback) on the > > >>V890 after about an hour of pho@'s stress test with INCARNATIONS=150: > > >> > > >>panic: uma_small_alloc: free page still has mappings! > > >>cpuid = 1 > > >>KDB: enter: panic > > >>[ thread pid 142 tid 100196 ] > > >>Stopped at kdb_enter+0x80: ta %xcc, 1 > > >>db> where > > >>Tracing pid 142 tid 100196 td 0xfffff8a016ace880 > > >>panic() at panic+0x20c > > >>uma_small_alloc() at uma_small_alloc+0xe8 > > >>keg_alloc_slab() at keg_alloc_slab+0xc8 > > >>keg_fetch_slab() at keg_fetch_slab+0x218 > > >>zone_fetch_slab() at zone_fetch_slab+0x44 > > >>uma_zalloc_arg() at uma_zalloc_arg+0x60c > > >>m_getm2() at m_getm2+0x134 > > >>m_uiotombuf() at m_uiotombuf+0x4c > > >>sosend_generic() at sosend_generic+0x420 > > >>sosend() at sosend+0x2c > > >>soo_write() at soo_write+0x3c > > >>dofilewrite() at dofilewrite+0x7c > > >>kern_writev() at kern_writev+0x38 > > >>write() at write+0x4c > > >>syscallenter() at syscallenter+0x270 > > >>syscall() at syscall+0x74 > > >>-- syscall (4, FreeBSD ELF64, write) %o7=0x101db4 -- > > >>userland() at 0x405936c8 > > >>user trace: trap %o7=0x101db4 > > >>pc 0x405936c8, sp 0x7fdffffd8a1 > > >>pc 0x101f44, sp 0x7fdffffd9a1 > > >>pc 0x104604, sp 0x7fdffffda81 > > >>pc 0x1046f0, sp 0x7fdffffdb51 > > >>pc 0x104994, sp 0x7fdffffdc21 > > >>pc 0x104d90, sp 0x7fdffffdd01 > > >>pc 0x101610, sp 0x7fdffffde41 > > >>pc 0x4020cff4, sp 0x7fdffffdf01 > > >>done > > >>db> > > >> > > >>I've got a crashdump on the V440 but discovered that gdb reports > > >>"GDB can't read core files on this machine." so it isn't much use. > > >>Any suggestions on how to debug this? > > >The VM and its interaction with the MD code are beyond me, I hope > > >Alan can chime in here. Reading through the code I see a possible > > >path which could lead to this though; tsb_tte_enter(), which is > > >the only place where TD_PV ever is set and also only in case of > > >managed pages, always calls pmap_cache_enter(), which together > > >with pmap_cache_remove() does the page color handling. In > > >pmap_remove_all() however, pmap_cache_remove() is only called for > > >managed pages, so for unmanaged pages we might miss the removal > > >of the mapping from the the color used. I've no idea though if > > >this actually is relevant, i.e. whether the VM ever calls > > >pmap_remove_all() for unmanaged pages. > > > > In HEAD, it does not. Other architectures have an assertion forbidding > > pmap_remove_all() calls on unmanaged pages. (Btw, I'm happy to add this > > assertion to sparc64's pmap if you like.) In older versions, calling > > pmap_remove_all() on unmanaged pages is expected to be a harmless NOP > > that's just a waste of cycles. > > > > With unmanaged pages, it is expected that pmap_remove() is used to > > destroy mappings before the page is freed. > > > > For years, vm_page_free{,_toq}() has asserted that the page has no > > managed mappings: > > > > if ((m->flags & PG_UNMANAGED) == 0) { > > vm_page_lock_assert(m, MA_OWNED); > > KASSERT(!pmap_page_is_mapped(m), > > ("vm_page_free_toq: freeing mapped page %p", m)); > > } > > > > Okay, then my theories don't hold. > > > As a debugging aid, you might want to add an additional check here on > > colors. > > I did that and it turns out to trigger rather quickly: > Trying to mount root from nfs: []... > NFS ROOT: 192.168.1.40:/usr/data/nfsroot/sparc64 > dc1: link state changed to UP > panic: vm_page_free_toq: free page 0xfffff80047b8a088 still has mappings! > cpuid = 0 > KDB: enter: panic > [ thread pid 1 tid 100001 ] > Stopped at kdb_enter+0x80: ta %xcc, 1 > db> bt > Tracing pid 1 tid 100001 td 0xfffff80041094000 > panic() at panic+0x20c > vm_page_free_toq() at vm_page_free_toq+0xb4 > vm_page_free_zero() at vm_page_free_zero+0x10 > pmap_release() at pmap_release+0x170 > vmspace_free() at vmspace_free+0x70 > vmspace_exec() at vmspace_exec+0x48 > exec_new_vmspace() at exec_new_vmspace+0x240 > exec_elf64_imgact() at exec_elf64_imgact+0x598 > kern_execve() at kern_execve+0x398 > execve() at execve+0x34 > start_init() at start_init+0x2ec > fork_exit() at fork_exit+0x9c > fork_trampoline() at fork_trampoline+0x8 > db> > > Further debugging shows that the page in question is one of the TSB > pages entered by pmap_pinit(). In pmap_release() vm_page_free_zero() > is called on these before pmap_qremove(), so there appears to be a > race in which these pages can get re-used before their mappings are > removed. I suspect that this might be related to your change in > r207648, but just reverting that one nowadays this triggers the > assertion in vm_page_free_toq() about the page lock not being held. > Anyway, I'm not sure what the right fix for this is; should > pmap_release() call pmap_qremove() on these pages one-by-one before > calling vm_page_free_zero() or maybe just call pmap_qremove() for > all of them before looping over them and calling vm_page_free_zero()? > Well, given that all uses of pmap_qremove() in the kernel except the one in the sparc64 pmap_release and two invocations in vfs_bio.c remove the pages before they are freed, unwired etc this seems to be a safe thing to do. Does the below patch look correct to you? Marius Index: kern/vfs_bio.c =================================================================== --- kern/vfs_bio.c (revision 223705) +++ kern/vfs_bio.c (working copy) @@ -1625,6 +1625,7 @@ vfs_vmio_release(struct buf *bp) int i; vm_page_t m; + pmap_qremove(trunc_page((vm_offset_t) bp->b_data), bp->b_npages); VM_OBJECT_LOCK(bp->b_bufobj->bo_object); for (i = 0; i < bp->b_npages; i++) { m = bp->b_pages[i]; @@ -1658,7 +1659,6 @@ vfs_vmio_release(struct buf *bp) vm_page_unlock(m); } VM_OBJECT_UNLOCK(bp->b_bufobj->bo_object); - pmap_qremove(trunc_page((vm_offset_t) bp->b_data), bp->b_npages); if (bp->b_bufsize) { bufspacewakeup(); @@ -3012,6 +3012,10 @@ allocbuf(struct buf *bp, int size) if (desiredpages < bp->b_npages) { vm_page_t m; + pmap_qremove((vm_offset_t)trunc_page( + (vm_offset_t)bp->b_data) + + (desiredpages << PAGE_SHIFT), + (bp->b_npages - desiredpages)); VM_OBJECT_LOCK(bp->b_bufobj->bo_object); for (i = desiredpages; i < bp->b_npages; i++) { /* @@ -3032,8 +3036,6 @@ allocbuf(struct buf *bp, int size) vm_page_unlock(m); } VM_OBJECT_UNLOCK(bp->b_bufobj->bo_object); - pmap_qremove((vm_offset_t) trunc_page((vm_offset_t)bp->b_data) + - (desiredpages << PAGE_SHIFT), (bp->b_npages - desiredpages)); bp->b_npages = desiredpages; } } else if (size > bp->b_bcount) { Index: sparc64/sparc64/pmap.c =================================================================== --- sparc64/sparc64/pmap.c (revision 223705) +++ sparc64/sparc64/pmap.c (working copy) @@ -1286,6 +1289,7 @@ pmap_release(pmap_t pm) pc->pc_pmap = NULL; mtx_unlock_spin(&sched_lock); + pmap_qremove((vm_offset_t)pm->pm_tsb, TSB_PAGES); obj = pm->pm_tsb_obj; VM_OBJECT_LOCK(obj); KASSERT(obj->ref_count == 1, ("pmap_release: tsbobj ref count != 1")); @@ -1297,7 +1301,6 @@ pmap_release(pmap_t pm) vm_page_free_zero(m); } VM_OBJECT_UNLOCK(obj); - pmap_qremove((vm_offset_t)pm->pm_tsb, TSB_PAGES); PMAP_LOCK_DESTROY(pm); } @@ -1379,6 +1382,8 @@ pmap_remove_all(vm_page_t m) struct tte *tp; vm_offset_t va; + KASSERT((m->flags & (PG_FICTITIOUS | PG_UNMANAGED)) == 0, + ("pmap_remove_all: page %p is not managed", m)); vm_page_lock_queues(); for (tp = TAILQ_FIRST(&m->md.tte_list); tp != NULL; tp = tpn) { tpn = TAILQ_NEXT(tp, tte_link); From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 5 18:12:51 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 6FA65106566B; Tue, 5 Jul 2011 18:12:51 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id 356608FC12; Tue, 5 Jul 2011 18:12:51 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 67FD92900EB; Tue, 5 Jul 2011 13:12:50 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 8PlT4woJldUC; Tue, 5 Jul 2011 13:12:50 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id A7D952900B4; Tue, 5 Jul 2011 13:12:49 -0500 (CDT) Message-ID: <4E135420.4080201@rice.edu> Date: Tue, 05 Jul 2011 13:12:48 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Marius Strobl References: <20110619220033.GA61397@server.vk2pj.dyndns.org> <20110622100524.GO14797@alchemy.franken.de> <20110629025433.GA48145@server.vk2pj.dyndns.org> <20110629175444.GH14797@alchemy.franken.de> <20110629220010.GA53017@pjdesk.au.alcatel-lucent.com> <20110629223008.GL14797@alchemy.franken.de> <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> <20110702002325.GS14797@alchemy.franken.de> <4E0F6B8D.8000500@rice.edu> <20110704214158.GX14797@alchemy.franken.de> <20110705160709.GA77843@alchemy.franken.de> In-Reply-To: <20110705160709.GA77843@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , "alc@freebsd.org" , 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, 05 Jul 2011 18:12:51 -0000 On 07/05/2011 11:07, Marius Strobl wrote: > On Mon, Jul 04, 2011 at 11:41:58PM +0200, Marius Strobl wrote: >> On Sat, Jul 02, 2011 at 02:03:41PM -0500, Alan Cox wrote: >>> On 07/01/2011 19:23, Marius Strobl wrote: >>>> On Fri, Jul 01, 2011 at 08:17:52AM +1000, Peter Jeremy wrote: >>>>> [Moving back on-list] >>>>> >>>>> On 2011-Jun-30 06:30:08 +0800, Marius Strobl >>>>> wrote: >>>>>> On Thu, Jun 30, 2011 at 08:00:10AM +1000, Peter Jeremy wrote: >>>>>>> On 2011-Jun-29 19:54:44 +0200, Marius Strobl >>>>>>> wrote: >>>>>>>> On Wed, Jun 29, 2011 at 12:54:33PM +1000, Peter Jeremy wrote: >>>>>>>>> My V890 has been running "make -j32 buildworld" in a loop for a >>>>>>>>> week now without problems so I think that was the problem. >>>>>>> OTOH, a V440 that has been running similar load for a similar period >>>>>>> died overnight with: >>>>>>> >>>>>>> panic: uma_small_alloc: free page still has mappings! >>>>>>> VNASSERT failed >>>>>>> cpuid = 3 >>>>>>> 0xfffff800079643c0: KDB: enter: panic >>>>> ... >>>>>>> I'm fairly sure that is the same kernel but will double-check and >>>>>>> investigate that panic further. >>>>> FWIW, that kernel didn't have the latest patchset (adding Zeus support). >>>> That shouldn't make a difference; the later version only adds the >>>> SPARC64 bits as you already noticed and adjusts the boot loader to >>>> compile again. I made no changes to the existing parts apart from >>>> fixing a comment. Besides I see no connection between fixing the >>>> gross user TLB flushing and the below problem so far. >>>> >>>>>> Ok, this appears to be an unrelated problem though. Alan, do you >>>>>> have an idea what could be causing this? >>>>> I managed to get the same panic (though different traceback) on the >>>>> V890 after about an hour of pho@'s stress test with INCARNATIONS=150: >>>>> >>>>> panic: uma_small_alloc: free page still has mappings! >>>>> cpuid = 1 >>>>> KDB: enter: panic >>>>> [ thread pid 142 tid 100196 ] >>>>> Stopped at kdb_enter+0x80: ta %xcc, 1 >>>>> db> where >>>>> Tracing pid 142 tid 100196 td 0xfffff8a016ace880 >>>>> panic() at panic+0x20c >>>>> uma_small_alloc() at uma_small_alloc+0xe8 >>>>> keg_alloc_slab() at keg_alloc_slab+0xc8 >>>>> keg_fetch_slab() at keg_fetch_slab+0x218 >>>>> zone_fetch_slab() at zone_fetch_slab+0x44 >>>>> uma_zalloc_arg() at uma_zalloc_arg+0x60c >>>>> m_getm2() at m_getm2+0x134 >>>>> m_uiotombuf() at m_uiotombuf+0x4c >>>>> sosend_generic() at sosend_generic+0x420 >>>>> sosend() at sosend+0x2c >>>>> soo_write() at soo_write+0x3c >>>>> dofilewrite() at dofilewrite+0x7c >>>>> kern_writev() at kern_writev+0x38 >>>>> write() at write+0x4c >>>>> syscallenter() at syscallenter+0x270 >>>>> syscall() at syscall+0x74 >>>>> -- syscall (4, FreeBSD ELF64, write) %o7=0x101db4 -- >>>>> userland() at 0x405936c8 >>>>> user trace: trap %o7=0x101db4 >>>>> pc 0x405936c8, sp 0x7fdffffd8a1 >>>>> pc 0x101f44, sp 0x7fdffffd9a1 >>>>> pc 0x104604, sp 0x7fdffffda81 >>>>> pc 0x1046f0, sp 0x7fdffffdb51 >>>>> pc 0x104994, sp 0x7fdffffdc21 >>>>> pc 0x104d90, sp 0x7fdffffdd01 >>>>> pc 0x101610, sp 0x7fdffffde41 >>>>> pc 0x4020cff4, sp 0x7fdffffdf01 >>>>> done >>>>> db> >>>>> >>>>> I've got a crashdump on the V440 but discovered that gdb reports >>>>> "GDB can't read core files on this machine." so it isn't much use. >>>>> Any suggestions on how to debug this? >>>> The VM and its interaction with the MD code are beyond me, I hope >>>> Alan can chime in here. Reading through the code I see a possible >>>> path which could lead to this though; tsb_tte_enter(), which is >>>> the only place where TD_PV ever is set and also only in case of >>>> managed pages, always calls pmap_cache_enter(), which together >>>> with pmap_cache_remove() does the page color handling. In >>>> pmap_remove_all() however, pmap_cache_remove() is only called for >>>> managed pages, so for unmanaged pages we might miss the removal >>>> of the mapping from the the color used. I've no idea though if >>>> this actually is relevant, i.e. whether the VM ever calls >>>> pmap_remove_all() for unmanaged pages. >>> In HEAD, it does not. Other architectures have an assertion forbidding >>> pmap_remove_all() calls on unmanaged pages. (Btw, I'm happy to add this >>> assertion to sparc64's pmap if you like.) In older versions, calling >>> pmap_remove_all() on unmanaged pages is expected to be a harmless NOP >>> that's just a waste of cycles. >>> >>> With unmanaged pages, it is expected that pmap_remove() is used to >>> destroy mappings before the page is freed. >>> >>> For years, vm_page_free{,_toq}() has asserted that the page has no >>> managed mappings: >>> >>> if ((m->flags& PG_UNMANAGED) == 0) { >>> vm_page_lock_assert(m, MA_OWNED); >>> KASSERT(!pmap_page_is_mapped(m), >>> ("vm_page_free_toq: freeing mapped page %p", m)); >>> } >>> >> Okay, then my theories don't hold. >> >>> As a debugging aid, you might want to add an additional check here on >>> colors. >> I did that and it turns out to trigger rather quickly: >> Trying to mount root from nfs: []... >> NFS ROOT: 192.168.1.40:/usr/data/nfsroot/sparc64 >> dc1: link state changed to UP >> panic: vm_page_free_toq: free page 0xfffff80047b8a088 still has mappings! >> cpuid = 0 >> KDB: enter: panic >> [ thread pid 1 tid 100001 ] >> Stopped at kdb_enter+0x80: ta %xcc, 1 >> db> bt >> Tracing pid 1 tid 100001 td 0xfffff80041094000 >> panic() at panic+0x20c >> vm_page_free_toq() at vm_page_free_toq+0xb4 >> vm_page_free_zero() at vm_page_free_zero+0x10 >> pmap_release() at pmap_release+0x170 >> vmspace_free() at vmspace_free+0x70 >> vmspace_exec() at vmspace_exec+0x48 >> exec_new_vmspace() at exec_new_vmspace+0x240 >> exec_elf64_imgact() at exec_elf64_imgact+0x598 >> kern_execve() at kern_execve+0x398 >> execve() at execve+0x34 >> start_init() at start_init+0x2ec >> fork_exit() at fork_exit+0x9c >> fork_trampoline() at fork_trampoline+0x8 >> db> >> >> Further debugging shows that the page in question is one of the TSB >> pages entered by pmap_pinit(). In pmap_release() vm_page_free_zero() >> is called on these before pmap_qremove(), so there appears to be a >> race in which these pages can get re-used before their mappings are >> removed. I suspect that this might be related to your change in >> r207648, but just reverting that one nowadays this triggers the >> assertion in vm_page_free_toq() about the page lock not being held. >> Anyway, I'm not sure what the right fix for this is; should >> pmap_release() call pmap_qremove() on these pages one-by-one before >> calling vm_page_free_zero() or maybe just call pmap_qremove() for >> all of them before looping over them and calling vm_page_free_zero()? >> > Well, given that all uses of pmap_qremove() in the kernel except > the one in the sparc64 pmap_release and two invocations in vfs_bio.c > remove the pages before they are freed, unwired etc this seems to be > a safe thing to do. Does the below patch look correct to you? > Basically, yes. However, I would suggest adding the KASSERT in pmap.c as a separate change. The pmap_qremove() changes should be MFCed to RELENG_8 and RELENG_7, but not the KASSERT change. > Index: kern/vfs_bio.c > =================================================================== > --- kern/vfs_bio.c (revision 223705) > +++ kern/vfs_bio.c (working copy) > @@ -1625,6 +1625,7 @@ vfs_vmio_release(struct buf *bp) > int i; > vm_page_t m; > > + pmap_qremove(trunc_page((vm_offset_t) bp->b_data), bp->b_npages); While you're here, please also remove the non-style(9) compliant space after the cast. > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > for (i = 0; i< bp->b_npages; i++) { > m = bp->b_pages[i]; > @@ -1658,7 +1659,6 @@ vfs_vmio_release(struct buf *bp) > vm_page_unlock(m); > } > VM_OBJECT_UNLOCK(bp->b_bufobj->bo_object); > - pmap_qremove(trunc_page((vm_offset_t) bp->b_data), bp->b_npages); > > if (bp->b_bufsize) { > bufspacewakeup(); > @@ -3012,6 +3012,10 @@ allocbuf(struct buf *bp, int size) > if (desiredpages< bp->b_npages) { > vm_page_t m; > > + pmap_qremove((vm_offset_t)trunc_page( > + (vm_offset_t)bp->b_data) + > + (desiredpages<< PAGE_SHIFT), > + (bp->b_npages - desiredpages)); > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > for (i = desiredpages; i< bp->b_npages; i++) { > /* > @@ -3032,8 +3036,6 @@ allocbuf(struct buf *bp, int size) > vm_page_unlock(m); > } > VM_OBJECT_UNLOCK(bp->b_bufobj->bo_object); > - pmap_qremove((vm_offset_t) trunc_page((vm_offset_t)bp->b_data) + > - (desiredpages<< PAGE_SHIFT), (bp->b_npages - desiredpages)); > bp->b_npages = desiredpages; > } > } else if (size> bp->b_bcount) { > Index: sparc64/sparc64/pmap.c > =================================================================== > --- sparc64/sparc64/pmap.c (revision 223705) > +++ sparc64/sparc64/pmap.c (working copy) > @@ -1286,6 +1289,7 @@ pmap_release(pmap_t pm) > pc->pc_pmap = NULL; > mtx_unlock_spin(&sched_lock); > > + pmap_qremove((vm_offset_t)pm->pm_tsb, TSB_PAGES); > obj = pm->pm_tsb_obj; > VM_OBJECT_LOCK(obj); > KASSERT(obj->ref_count == 1, ("pmap_release: tsbobj ref count != 1")); > @@ -1297,7 +1301,6 @@ pmap_release(pmap_t pm) > vm_page_free_zero(m); > } > VM_OBJECT_UNLOCK(obj); > - pmap_qremove((vm_offset_t)pm->pm_tsb, TSB_PAGES); > PMAP_LOCK_DESTROY(pm); > } > > @@ -1379,6 +1382,8 @@ pmap_remove_all(vm_page_t m) > struct tte *tp; > vm_offset_t va; > > + KASSERT((m->flags& (PG_FICTITIOUS | PG_UNMANAGED)) == 0, > + ("pmap_remove_all: page %p is not managed", m)); > vm_page_lock_queues(); > for (tp = TAILQ_FIRST(&m->md.tte_list); tp != NULL; tp = tpn) { > tpn = TAILQ_NEXT(tp, tte_link); > From owner-freebsd-sparc64@FreeBSD.ORG Tue Jul 5 19:01:32 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 84609106566C; Tue, 5 Jul 2011 19:01:32 +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 D4D7C8FC08; Tue, 5 Jul 2011 19:01:31 +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 p65J1QO6079094; Tue, 5 Jul 2011 21:01:26 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p65J1QdS079093; Tue, 5 Jul 2011 21:01:26 +0200 (CEST) (envelope-from marius) Date: Tue, 5 Jul 2011 21:01:26 +0200 From: Marius Strobl To: Alan Cox Message-ID: <20110705190126.GE14797@alchemy.franken.de> References: <20110629025433.GA48145@server.vk2pj.dyndns.org> <20110629175444.GH14797@alchemy.franken.de> <20110629220010.GA53017@pjdesk.au.alcatel-lucent.com> <20110629223008.GL14797@alchemy.franken.de> <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> <20110702002325.GS14797@alchemy.franken.de> <4E0F6B8D.8000500@rice.edu> <20110704214158.GX14797@alchemy.franken.de> <20110705160709.GA77843@alchemy.franken.de> <4E135420.4080201@rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E135420.4080201@rice.edu> User-Agent: Mutt/1.4.2.3i Cc: Peter Jeremy , "alc@freebsd.org" , 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, 05 Jul 2011 19:01:32 -0000 On Tue, Jul 05, 2011 at 01:12:48PM -0500, Alan Cox wrote: > On 07/05/2011 11:07, Marius Strobl wrote: > >On Mon, Jul 04, 2011 at 11:41:58PM +0200, Marius Strobl wrote: > >>On Sat, Jul 02, 2011 at 02:03:41PM -0500, Alan Cox wrote: > >>>On 07/01/2011 19:23, Marius Strobl wrote: > >>>>On Fri, Jul 01, 2011 at 08:17:52AM +1000, Peter Jeremy wrote: > >>>>>[Moving back on-list] > >>>>> > >>>>>On 2011-Jun-30 06:30:08 +0800, Marius Strobl > >>>>>wrote: > >>>>>>On Thu, Jun 30, 2011 at 08:00:10AM +1000, Peter Jeremy wrote: > >>>>>>>On 2011-Jun-29 19:54:44 +0200, Marius > >>>>>>>Strobl > >>>>>>>wrote: > >>>>>>>>On Wed, Jun 29, 2011 at 12:54:33PM +1000, Peter Jeremy wrote: > >>>>>>>>>My V890 has been running "make -j32 buildworld" in a loop for a > >>>>>>>>>week now without problems so I think that was the problem. > >>>>>>>OTOH, a V440 that has been running similar load for a similar period > >>>>>>>died overnight with: > >>>>>>> > >>>>>>>panic: uma_small_alloc: free page still has mappings! > >>>>>>>VNASSERT failed > >>>>>>>cpuid = 3 > >>>>>>>0xfffff800079643c0: KDB: enter: panic > >>>>>... > >>>>>>>I'm fairly sure that is the same kernel but will double-check and > >>>>>>>investigate that panic further. > >>>>>FWIW, that kernel didn't have the latest patchset (adding Zeus > >>>>>support). > >>>>That shouldn't make a difference; the later version only adds the > >>>>SPARC64 bits as you already noticed and adjusts the boot loader to > >>>>compile again. I made no changes to the existing parts apart from > >>>>fixing a comment. Besides I see no connection between fixing the > >>>>gross user TLB flushing and the below problem so far. > >>>> > >>>>>>Ok, this appears to be an unrelated problem though. Alan, do you > >>>>>>have an idea what could be causing this? > >>>>>I managed to get the same panic (though different traceback) on the > >>>>>V890 after about an hour of pho@'s stress test with INCARNATIONS=150: > >>>>> > >>>>>panic: uma_small_alloc: free page still has mappings! > >>>>>cpuid = 1 > >>>>>KDB: enter: panic > >>>>>[ thread pid 142 tid 100196 ] > >>>>>Stopped at kdb_enter+0x80: ta %xcc, 1 > >>>>>db> where > >>>>>Tracing pid 142 tid 100196 td 0xfffff8a016ace880 > >>>>>panic() at panic+0x20c > >>>>>uma_small_alloc() at uma_small_alloc+0xe8 > >>>>>keg_alloc_slab() at keg_alloc_slab+0xc8 > >>>>>keg_fetch_slab() at keg_fetch_slab+0x218 > >>>>>zone_fetch_slab() at zone_fetch_slab+0x44 > >>>>>uma_zalloc_arg() at uma_zalloc_arg+0x60c > >>>>>m_getm2() at m_getm2+0x134 > >>>>>m_uiotombuf() at m_uiotombuf+0x4c > >>>>>sosend_generic() at sosend_generic+0x420 > >>>>>sosend() at sosend+0x2c > >>>>>soo_write() at soo_write+0x3c > >>>>>dofilewrite() at dofilewrite+0x7c > >>>>>kern_writev() at kern_writev+0x38 > >>>>>write() at write+0x4c > >>>>>syscallenter() at syscallenter+0x270 > >>>>>syscall() at syscall+0x74 > >>>>>-- syscall (4, FreeBSD ELF64, write) %o7=0x101db4 -- > >>>>>userland() at 0x405936c8 > >>>>>user trace: trap %o7=0x101db4 > >>>>>pc 0x405936c8, sp 0x7fdffffd8a1 > >>>>>pc 0x101f44, sp 0x7fdffffd9a1 > >>>>>pc 0x104604, sp 0x7fdffffda81 > >>>>>pc 0x1046f0, sp 0x7fdffffdb51 > >>>>>pc 0x104994, sp 0x7fdffffdc21 > >>>>>pc 0x104d90, sp 0x7fdffffdd01 > >>>>>pc 0x101610, sp 0x7fdffffde41 > >>>>>pc 0x4020cff4, sp 0x7fdffffdf01 > >>>>>done > >>>>>db> > >>>>> > >>>>>I've got a crashdump on the V440 but discovered that gdb reports > >>>>>"GDB can't read core files on this machine." so it isn't much use. > >>>>>Any suggestions on how to debug this? > >>>>The VM and its interaction with the MD code are beyond me, I hope > >>>>Alan can chime in here. Reading through the code I see a possible > >>>>path which could lead to this though; tsb_tte_enter(), which is > >>>>the only place where TD_PV ever is set and also only in case of > >>>>managed pages, always calls pmap_cache_enter(), which together > >>>>with pmap_cache_remove() does the page color handling. In > >>>>pmap_remove_all() however, pmap_cache_remove() is only called for > >>>>managed pages, so for unmanaged pages we might miss the removal > >>>>of the mapping from the the color used. I've no idea though if > >>>>this actually is relevant, i.e. whether the VM ever calls > >>>>pmap_remove_all() for unmanaged pages. > >>>In HEAD, it does not. Other architectures have an assertion forbidding > >>>pmap_remove_all() calls on unmanaged pages. (Btw, I'm happy to add this > >>>assertion to sparc64's pmap if you like.) In older versions, calling > >>>pmap_remove_all() on unmanaged pages is expected to be a harmless NOP > >>>that's just a waste of cycles. > >>> > >>>With unmanaged pages, it is expected that pmap_remove() is used to > >>>destroy mappings before the page is freed. > >>> > >>>For years, vm_page_free{,_toq}() has asserted that the page has no > >>>managed mappings: > >>> > >>> if ((m->flags& PG_UNMANAGED) == 0) { > >>> vm_page_lock_assert(m, MA_OWNED); > >>> KASSERT(!pmap_page_is_mapped(m), > >>> ("vm_page_free_toq: freeing mapped page %p", m)); > >>> } > >>> > >>Okay, then my theories don't hold. > >> > >>>As a debugging aid, you might want to add an additional check here on > >>>colors. > >>I did that and it turns out to trigger rather quickly: > >>Trying to mount root from nfs: []... > >>NFS ROOT: 192.168.1.40:/usr/data/nfsroot/sparc64 > >>dc1: link state changed to UP > >>panic: vm_page_free_toq: free page 0xfffff80047b8a088 still has mappings! > >>cpuid = 0 > >>KDB: enter: panic > >>[ thread pid 1 tid 100001 ] > >>Stopped at kdb_enter+0x80: ta %xcc, 1 > >>db> bt > >>Tracing pid 1 tid 100001 td 0xfffff80041094000 > >>panic() at panic+0x20c > >>vm_page_free_toq() at vm_page_free_toq+0xb4 > >>vm_page_free_zero() at vm_page_free_zero+0x10 > >>pmap_release() at pmap_release+0x170 > >>vmspace_free() at vmspace_free+0x70 > >>vmspace_exec() at vmspace_exec+0x48 > >>exec_new_vmspace() at exec_new_vmspace+0x240 > >>exec_elf64_imgact() at exec_elf64_imgact+0x598 > >>kern_execve() at kern_execve+0x398 > >>execve() at execve+0x34 > >>start_init() at start_init+0x2ec > >>fork_exit() at fork_exit+0x9c > >>fork_trampoline() at fork_trampoline+0x8 > >>db> > >> > >>Further debugging shows that the page in question is one of the TSB > >>pages entered by pmap_pinit(). In pmap_release() vm_page_free_zero() > >>is called on these before pmap_qremove(), so there appears to be a > >>race in which these pages can get re-used before their mappings are > >>removed. I suspect that this might be related to your change in > >>r207648, but just reverting that one nowadays this triggers the > >>assertion in vm_page_free_toq() about the page lock not being held. > >>Anyway, I'm not sure what the right fix for this is; should > >>pmap_release() call pmap_qremove() on these pages one-by-one before > >>calling vm_page_free_zero() or maybe just call pmap_qremove() for > >>all of them before looping over them and calling vm_page_free_zero()? > >> > >Well, given that all uses of pmap_qremove() in the kernel except > >the one in the sparc64 pmap_release and two invocations in vfs_bio.c > >remove the pages before they are freed, unwired etc this seems to be > >a safe thing to do. Does the below patch look correct to you? > > > > Basically, yes. However, I would suggest adding the KASSERT in pmap.c > as a separate change. The pmap_qremove() changes should be MFCed to > RELENG_8 and RELENG_7, but not the KASSERT change. Okay, thanks! > > >Index: kern/vfs_bio.c > >=================================================================== > >--- kern/vfs_bio.c (revision 223705) > >+++ kern/vfs_bio.c (working copy) > >@@ -1625,6 +1625,7 @@ vfs_vmio_release(struct buf *bp) > > int i; > > vm_page_t m; > > > >+ pmap_qremove(trunc_page((vm_offset_t) bp->b_data), bp->b_npages); > > While you're here, please also remove the non-style(9) compliant space > after the cast. > Done. Peter, could you please test again with at least r223795 and the below patch but no additional change to pmap.c? Marius Index: vm/vm_page.c =================================================================== --- vm/vm_page.c (revision 223705) +++ vm/vm_page.c (working copy) @@ -1741,6 +1741,10 @@ vm_page_free_toq(vm_page_t m) KASSERT(!pmap_page_is_mapped(m), ("vm_page_free_toq: freeing mapped page %p", m)); } +#ifdef __sparc64__ + KASSERT(m->md.colors[0] == 0 && m->md.colors[1] == 0, + ("vm_page_free_toq: free page %p still has mappings!", m)); +#endif PCPU_INC(cnt.v_tfree); if (VM_PAGE_IS_FREE(m)) From owner-freebsd-sparc64@FreeBSD.ORG Wed Jul 6 04:41: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 E632E106564A; Wed, 6 Jul 2011 04:41:52 +0000 (UTC) (envelope-from peter.jeremy@alcatel-lucent.com) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by mx1.freebsd.org (Postfix) with ESMTP id 41BB68FC08; Wed, 6 Jul 2011 04:41:51 +0000 (UTC) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p664fon7005849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jul 2011 23:41:50 -0500 (CDT) Received: from unixmail.au.alcatel-lucent.com (unixmail.au.alcatel-lucent.com [139.188.42.130]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p664fkov026448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jul 2011 23:41:49 -0500 Received: from insmb.au.alcatel-lucent.com (insmb.au.alcatel-lucent.com [139.188.42.184]) by unixmail.au.alcatel-lucent.com (8.13.8+Sun/8.13.3) with ESMTP id p664fjOn002877; Wed, 6 Jul 2011 14:41:45 +1000 (EST) Received: from pjdesk.au.alcatel-lucent.com (pjdesk.au.alcatel-lucent.com [139.188.2.2]) by insmb.au.alcatel-lucent.com (8.13.8+Sun/8.13.8) with ESMTP id p664Qhww016618; Wed, 6 Jul 2011 14:26:44 +1000 (EST) X-Bogosity: Ham, spamicity=0.000000 Received: from pjdesk.au.alcatel-lucent.com (localhost [127.0.0.1]) by pjdesk.au.alcatel-lucent.com (8.14.4/8.14.4) with ESMTP id p664QbTr003127; Wed, 6 Jul 2011 14:26:37 +1000 (EST) (envelope-from peter.jeremy@alcatel-lucent.com) Received: (from pjeremy@localhost) by pjdesk.au.alcatel-lucent.com (8.14.4/8.14.4/Submit) id p664QYNH003126; Wed, 6 Jul 2011 14:26:34 +1000 (EST) (envelope-from peter.jeremy@alcatel-lucent.com) Date: Wed, 6 Jul 2011 14:26:34 +1000 From: Peter Jeremy To: Marius Strobl Message-ID: <20110706042634.GP65891@pjdesk.au.alcatel-lucent.com> References: <20110629175444.GH14797@alchemy.franken.de> <20110629220010.GA53017@pjdesk.au.alcatel-lucent.com> <20110629223008.GL14797@alchemy.franken.de> <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> <20110702002325.GS14797@alchemy.franken.de> <4E0F6B8D.8000500@rice.edu> <20110704214158.GX14797@alchemy.franken.de> <20110705160709.GA77843@alchemy.franken.de> <4E135420.4080201@rice.edu> <20110705190126.GE14797@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q5r20fdKX+PFtYHw" Content-Disposition: inline In-Reply-To: <20110705190126.GE14797@alchemy.franken.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "alc@freebsd.org" , "freebsd-sparc64@freebsd.org" , Alan Cox 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: Wed, 06 Jul 2011 04:41:53 -0000 --q5r20fdKX+PFtYHw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jul-06 03:01:26 +0800, Marius Strobl wr= ote: >Peter, could you please test again with at least r223795 and the below >patch but no additional change to pmap.c? I've updated my V890 to r223802 with no patches other than the vm_page.c one you posted and started running pho@'s stress test with INCARNATIONS=3D150. After about 1=BD hr, it reported: "witness_lock_list_get: witness exhausted" I presume I need to increase LOCK_CHILDCOUNT to avoid this. sysctl shows: debug.witness.sleep_cnt: 132 debug.witness.spin_cnt: 0 debug.witness.free_cnt: 751 debug.witness.badstacks: Witness not running debug.witness.fullgraph: Witness not running debug.witness.skipspin: 1 debug.witness.trace: 1 debug.witness.kdb: 0 debug.witness.watch: -1 After about 2=BC hrs, 'thr1' stopped making progress: It has 77 zombies and a further 5 processes stuck in "urdlck" (no other processes appear stuck). "procstat -k" shows: 8732 100898 thr1 - mi_switch sleepq_switch slee= pq_catch_signals sleepq_wait_sig _sleep kern_wait wait4 syscallenter syscal= l=20 8881 195433 thr1 - mi_switch sleepq_switch slee= pq_catch_signals sleepq_wait_sig _sleep do_rw_rdlock __umtx_op_rw_rdlock _u= mtx_op syscallenter syscall=20 And DDB for one of the stuck processes shows db> trace 8881 Tracing pid 8881 tid 195433 td 0xfffff8b0a2e72880 mi_switch() at mi_switch+0x2a8 sleepq_switch() at sleepq_switch+0x1cc sleepq_catch_signals() at sleepq_catch_signals+0x130 sleepq_wait_sig() at sleepq_wait_sig+0x8 _sleep() at _sleep+0x41c do_rw_rdlock() at do_rw_rdlock+0x7e4 __umtx_op_rw_rdlock() at __umtx_op_rw_rdlock+0x1c _umtx_op() at _umtx_op+0x3c syscallenter() at syscallenter+0x270 syscall() at syscall+0x74 -- syscall (454, FreeBSD ELF64, _umtx_op) %o7=3D0x40479574 -- userland() at 0x4047957c user trace: trap %o7=3D0x40479574 pc 0x4047957c, sp 0x7fdffffc561 pc 0x7fdffffd1c0, sp 0x40365a10 pc 0x90000000000125a, sp 0xac00002d11220000 Unfortunately, I'm somewhat at a loss as to how to investigate this further. In particular, DDB doesn't show the lock details and kgdb doesn't work. What is involved in getting kgdb to work on sparc64? --=20 Peter Jeremy --q5r20fdKX+PFtYHw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4T4/oACgkQ/opHv/APuIc8rQCbB95A2IXUVj5vD51hjVxtuEFJ lU8Amwck2OBYI1hkcCU3UBmVpFNDbeuo =BomO -----END PGP SIGNATURE----- --q5r20fdKX+PFtYHw-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Jul 6 09:18:46 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 381F8106566B for ; Wed, 6 Jul 2011 09:18:46 +0000 (UTC) (envelope-from geodni@free.fr) Received: from smtp2-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::11]) by mx1.freebsd.org (Postfix) with ESMTP id A3BF68FC13 for ; Wed, 6 Jul 2011 09:18:44 +0000 (UTC) Received: from dune.gravos.com (unknown [78.226.156.55]) by smtp2-g21.free.fr (Postfix) with ESMTP id 8B6594B007E for ; Wed, 6 Jul 2011 11:18:39 +0200 (CEST) Message-ID: <4E1428E7.2040906@free.fr> Date: Wed, 06 Jul 2011 11:20:39 +0200 From: Denis Saget User-Agent: Thunderbird 2.0.0.24 (X11/20110126) MIME-Version: 1.0 To: freebsd-sparc64@freebsd.org References: <4D77D2BF.1090106@free.fr> <20110309205141.GB18229@lonesome.com> <20110310193640.GA53044@server.vk2pj.dyndns.org> In-Reply-To: <20110310193640.GA53044@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [FreeBSD 8.2 release] boot from dvd fails on Sun Fire T2000 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, 06 Jul 2011 09:18:46 -0000 Peter Jeremy a écrit : > On 2011-Mar-09 14:51:41 -0600, Mark Linimon wrote: > >> AFAIK sun4v support was never completed. Someone, please correct me >> if I am wrong. >> > > No, you're not wrong. > > I had a look at it a couple of years ago but I can only allocate a > LDom guest to FreeBSD and FreeBSD has no support for any of the > virtualised devices. Implementing the infrastructure to work with the > sun4v hypervisor is a non-trivial task and I never managed to make > any real progress. > > I'm unaware of anyone else who has done anything in the past few years. > > Hello Still no progress on that platform ? Which BSD like will best use SunFire T2000, OpenBSD or NetBSD ? Or perhaps it's better using the platform with LDOMs and OpenBSD as a guest ? Any advice is really appreciated. Denis From owner-freebsd-sparc64@FreeBSD.ORG Wed Jul 6 10:39:16 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 812961065672; Wed, 6 Jul 2011 10:39:16 +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 EF7A48FC08; Wed, 6 Jul 2011 10:39:15 +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 p66AdAi3084240; Wed, 6 Jul 2011 12:39:10 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p66AdAf2084239; Wed, 6 Jul 2011 12:39:10 +0200 (CEST) (envelope-from marius) Date: Wed, 6 Jul 2011 12:39:10 +0200 From: Marius Strobl To: Peter Jeremy Message-ID: <20110706103910.GG14797@alchemy.franken.de> References: <20110629220010.GA53017@pjdesk.au.alcatel-lucent.com> <20110629223008.GL14797@alchemy.franken.de> <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> <20110702002325.GS14797@alchemy.franken.de> <4E0F6B8D.8000500@rice.edu> <20110704214158.GX14797@alchemy.franken.de> <20110705160709.GA77843@alchemy.franken.de> <4E135420.4080201@rice.edu> <20110705190126.GE14797@alchemy.franken.de> <20110706042634.GP65891@pjdesk.au.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110706042634.GP65891@pjdesk.au.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Cc: "alc@freebsd.org" , "freebsd-sparc64@freebsd.org" , Alan Cox 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: Wed, 06 Jul 2011 10:39:16 -0000 On Wed, Jul 06, 2011 at 02:26:34PM +1000, Peter Jeremy wrote: > On 2011-Jul-06 03:01:26 +0800, Marius Strobl wrote: > >Peter, could you please test again with at least r223795 and the below > >patch but no additional change to pmap.c? > > I've updated my V890 to r223802 with no patches other than the > vm_page.c one you posted and started running pho@'s stress test with > INCARNATIONS=150. > > After about 1? hr, it reported: "witness_lock_list_get: witness exhausted" > I presume I need to increase LOCK_CHILDCOUNT to avoid this. sysctl shows: > debug.witness.sleep_cnt: 132 > debug.witness.spin_cnt: 0 > debug.witness.free_cnt: 751 > debug.witness.badstacks: Witness not running > debug.witness.fullgraph: Witness not running > debug.witness.skipspin: 1 > debug.witness.trace: 1 > debug.witness.kdb: 0 > debug.witness.watch: -1 > > After about 2? hrs, 'thr1' stopped making progress: It has 77 zombies > and a further 5 processes stuck in "urdlck" (no other processes appear > stuck). "procstat -k" shows: > 8732 100898 thr1 - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep kern_wait wait4 syscallenter syscall > 8881 195433 thr1 - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep do_rw_rdlock __umtx_op_rw_rdlock _umtx_op syscallenter syscall > > And DDB for one of the stuck processes shows > db> trace 8881 > Tracing pid 8881 tid 195433 td 0xfffff8b0a2e72880 > mi_switch() at mi_switch+0x2a8 > sleepq_switch() at sleepq_switch+0x1cc > sleepq_catch_signals() at sleepq_catch_signals+0x130 > sleepq_wait_sig() at sleepq_wait_sig+0x8 > _sleep() at _sleep+0x41c > do_rw_rdlock() at do_rw_rdlock+0x7e4 > __umtx_op_rw_rdlock() at __umtx_op_rw_rdlock+0x1c > _umtx_op() at _umtx_op+0x3c > syscallenter() at syscallenter+0x270 > syscall() at syscall+0x74 > -- syscall (454, FreeBSD ELF64, _umtx_op) %o7=0x40479574 -- > userland() at 0x4047957c > user trace: trap %o7=0x40479574 > pc 0x4047957c, sp 0x7fdffffc561 > pc 0x7fdffffd1c0, sp 0x40365a10 > pc 0x90000000000125a, sp 0xac00002d11220000 What line does mi_switch+0x2a8 translate to? > > Unfortunately, I'm somewhat at a loss as to how to investigate this > further. In particular, DDB doesn't show the lock details and kgdb > doesn't work. > > What is involved in getting kgdb to work on sparc64? > I don't know. kgdb never really worked for me on any architecture so I didn't care about it and continued to use gdb53. At least for x86 kgdb apparently has been fixed since then though. The following is a sparc64 package of gdb53, which still has the '-k' option: http://people.freebsd.org/~marius/gdb-5.3_1%2c1.tbz Marius From owner-freebsd-sparc64@FreeBSD.ORG Wed Jul 6 22:44:14 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 A8FFE1065670; Wed, 6 Jul 2011 22:44:14 +0000 (UTC) (envelope-from peter.jeremy@alcatel-lucent.com) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 0C3168FC08; Wed, 6 Jul 2011 22:44:13 +0000 (UTC) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p66Mi8nC027998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2011 17:44:08 -0500 (CDT) Received: from unixmail.au.alcatel-lucent.com (unixmail.au.alcatel-lucent.com [139.188.42.130]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p66Mi4DN030151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Jul 2011 17:44:08 -0500 Received: from insmb.au.alcatel-lucent.com (insmb.au.alcatel-lucent.com [139.188.42.184]) by unixmail.au.alcatel-lucent.com (8.13.8+Sun/8.13.3) with ESMTP id p66Mi3QY000433; Thu, 7 Jul 2011 08:44:03 +1000 (EST) Received: from pjdesk.au.alcatel-lucent.com (pjdesk.au.alcatel-lucent.com [139.188.2.2]) by insmb.au.alcatel-lucent.com (8.13.8+Sun/8.13.8) with ESMTP id p66MSwQM022738; Thu, 7 Jul 2011 08:28:59 +1000 (EST) X-Bogosity: Ham, spamicity=0.000000 Received: from pjdesk.au.alcatel-lucent.com (localhost [127.0.0.1]) by pjdesk.au.alcatel-lucent.com (8.14.4/8.14.4) with ESMTP id p66MSrj6006937; Thu, 7 Jul 2011 08:28:53 +1000 (EST) (envelope-from peter.jeremy@alcatel-lucent.com) Received: (from pjeremy@localhost) by pjdesk.au.alcatel-lucent.com (8.14.4/8.14.4/Submit) id p66MSp1c006936; Thu, 7 Jul 2011 08:28:51 +1000 (EST) (envelope-from peter.jeremy@alcatel-lucent.com) Date: Thu, 7 Jul 2011 08:28:51 +1000 From: Peter Jeremy To: Marius Strobl Message-ID: <20110706222851.GQ65891@pjdesk.au.alcatel-lucent.com> References: <20110629223008.GL14797@alchemy.franken.de> <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> <20110702002325.GS14797@alchemy.franken.de> <4E0F6B8D.8000500@rice.edu> <20110704214158.GX14797@alchemy.franken.de> <20110705160709.GA77843@alchemy.franken.de> <4E135420.4080201@rice.edu> <20110705190126.GE14797@alchemy.franken.de> <20110706042634.GP65891@pjdesk.au.alcatel-lucent.com> <20110706103910.GG14797@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aziWXe2aaRGlkyg3" Content-Disposition: inline In-Reply-To: <20110706103910.GG14797@alchemy.franken.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "alc@freebsd.org" , "freebsd-sparc64@freebsd.org" , Alan Cox 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: Wed, 06 Jul 2011 22:44:14 -0000 --aziWXe2aaRGlkyg3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jul-06 18:39:10 +0800, Marius Strobl wr= ote: >On Wed, Jul 06, 2011 at 02:26:34PM +1000, Peter Jeremy wrote: >> And DDB for one of the stuck processes shows >> db> trace 8881 >> Tracing pid 8881 tid 195433 td 0xfffff8b0a2e72880 >> mi_switch() at mi_switch+0x2a8 >> sleepq_switch() at sleepq_switch+0x1cc >> sleepq_catch_signals() at sleepq_catch_signals+0x130 >> sleepq_wait_sig() at sleepq_wait_sig+0x8 >> _sleep() at _sleep+0x41c >> do_rw_rdlock() at do_rw_rdlock+0x7e4 >> __umtx_op_rw_rdlock() at __umtx_op_rw_rdlock+0x1c >> _umtx_op() at _umtx_op+0x3c >> syscallenter() at syscallenter+0x270 >> syscall() at syscall+0x74 >> -- syscall (454, FreeBSD ELF64, _umtx_op) %o7=3D0x40479574 -- >> userland() at 0x4047957c >> user trace: trap %o7=3D0x40479574 >> pc 0x4047957c, sp 0x7fdffffc561 >> pc 0x7fdffffd1c0, sp 0x40365a10 >> pc 0x90000000000125a, sp 0xac00002d11220000 > >What line does mi_switch+0x2a8 translate to? 0xc0503628 : call 0xc0528ba0 448 sched_switch(td, newtd, flags); The system is still running so I think the bigger issue is why none of the processes can grab the mutex. >sparc64 package of gdb53, which still has the '-k' option: >http://people.freebsd.org/~marius/gdb-5.3_1%2c1.tbz Unfortunately, it doesn't like me: # gdb53 -k /usr/obj/usr/src/sys/GENERIC/kernel.debug /dev/mem GNU gdb 5.3 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc64-unknown-freebsd9.0"... panic messages: --- dmesg: kvm_nlist: No such file or directory --- ---Can't read userspace from dump, or kernel process--- (kgdb) where ---Can't read userspace from dump, or kernel process--- (kgdb) disas mi_switch Segmentation fault (core dumped) --=20 Peter Jeremy --aziWXe2aaRGlkyg3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4U4aMACgkQ/opHv/APuIcuUwCfeWs4HZnRUUZ8PSRrcLBuwrhJ f3gAoIAs3B+u9sBoc+AYo0UC/CMftpuN =Vi9c -----END PGP SIGNATURE----- --aziWXe2aaRGlkyg3-- From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 9 21:22:55 2011 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 73D471065673; Sat, 9 Jul 2011 21:22:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1CC228FC19; Sat, 9 Jul 2011 21:22:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p69LMseN058824; Sat, 9 Jul 2011 17:22:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p69LMski058819; Sat, 9 Jul 2011 21:22:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 9 Jul 2011 21:22:54 GMT Message-Id: <201107092122.p69LMski058819@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head 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: Sat, 09 Jul 2011 21:22:55 -0000 TB --- 2011-07-09 20:28:46 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-09 20:28:46 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-09 20:28:46 - cleaning the object tree TB --- 2011-07-09 20:29:03 - cvsupping the source tree TB --- 2011-07-09 20:29:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-09 20:29:16 - building world TB --- 2011-07-09 20:29:16 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-09 20:29:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-09 20:29:16 - TARGET=sparc64 TB --- 2011-07-09 20:29:16 - TARGET_ARCH=sparc64 TB --- 2011-07-09 20:29:16 - TZ=UTC TB --- 2011-07-09 20:29:16 - __MAKE_CONF=/dev/null TB --- 2011-07-09 20:29:16 - cd /src TB --- 2011-07-09 20:29:16 - /usr/bin/make -B buildworld >>> World build started on Sat Jul 9 20:29:17 UTC 2011 >>> 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 [...] gzip -cn /src/share/man/man9/vm_map_madvise.9 > vm_map_madvise.9.gz gzip -cn /src/share/man/man9/vm_map_max.9 > vm_map_max.9.gz gzip -cn /src/share/man/man9/vm_map_protect.9 > vm_map_protect.9.gz gzip -cn /src/share/man/man9/vm_map_remove.9 > vm_map_remove.9.gz gzip -cn /src/share/man/man9/vm_map_simplify_entry.9 > vm_map_simplify_entry.9.gz gzip -cn /src/share/man/man9/vm_map_stack.9 > vm_map_stack.9.gz gzip -cn /src/share/man/man9/vm_map_submap.9 > vm_map_submap.9.gz make: don't know how to make vm_map_sync.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-09 21:22:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-09 21:22:54 - ERROR: failed to build world TB --- 2011-07-09 21:22:54 - 2440.01 user 600.23 system 3247.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full