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