Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Jul 2011 12:39:10 +0200
From:      Marius Strobl <marius@alchemy.franken.de>
To:        Peter Jeremy <peter.jeremy@alcatel-lucent.com>
Cc:        "alc@freebsd.org" <alc@freebsd.org>, "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org>, Alan Cox <alc@rice.edu>
Subject:   Re: 'make -j16 universe' gives SIReset
Message-ID:  <20110706103910.GG14797@alchemy.franken.de>
In-Reply-To: <20110706042634.GP65891@pjdesk.au.alcatel-lucent.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 06, 2011 at 02:26:34PM +1000, Peter Jeremy wrote:
> On 2011-Jul-06 03:01:26 +0800, Marius Strobl <marius@alchemy.franken.de> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110706103910.GG14797>