Date: Wed, 22 Jun 2011 12:05:24 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Peter Jeremy <peterjeremy@acm.org> Cc: freebsd-sparc64@freebsd.org Subject: Re: 'make -j16 universe' gives SIReset Message-ID: <20110622100524.GO14797@alchemy.franken.de> In-Reply-To: <20110619220033.GA61397@server.vk2pj.dyndns.org> References: <20110526234728.GA69750@server.vk2pj.dyndns.org> <20110527120659.GA78000@alchemy.franken.de> <20110601231237.GA5267@server.vk2pj.dyndns.org> <20110608224801.GB35494@alchemy.franken.de> <20110613235144.GA12470@server.vk2pj.dyndns.org> <20110615233445.GZ7064@alchemy.franken.de> <20110619220033.GA61397@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 20, 2011 at 08:00:34AM +1000, Peter Jeremy wrote: > On 2011-Jun-16 01:34:45 +0200, Marius Strobl <marius@alchemy.franken.de> wrote: > >You could try whether the below patch sufficiently reduces the lock > >coverage to avoid these. For stable/8 you'll probably need to apply > >the second chunk by hand. > > Well, it lasted through 30 hours of 'make -j32 universe' (on its 7th > cycle) before panicing with a 'spin lock held too long' on sched lock. Okay, given that it considerably improves the situation though I suspect that the problem is that we instantly begin to fault on kernel mappings once we flush all unlocked TLB entries in order to get rid of the user mappings, which in case of cpu_switch() still is covered by sched_lock. That would mean that we should use a fine grained approach instead as the current one doesn't behave/ scale well even if sched_lock wasn't be (ab)used here. Could you please give the following patch a try on top of what you already have? http://people.freebsd.org/~marius/sparc64_flush_user_no_sledgehammer.diff Note that this version is incomplete in that it breaks compiling the loader so you won't be able to build world with it. > Along the way, I got 4 isp_watchdog timeouts (and subsequent 'bad > request handle' reports. > > Do you have any ideas why the panics aren't dropping into DDB? > No, not really. However, the remaining contenders are cpu_switch() and the scheduler itself and I'm not sure whether one can easily panic when in there. It would be interesting to know if you get the "timeout stopping cpus" in generic_stop_cpus(), compiling the whole kernel with DIAGNOSTIC is overkill though. Unfortunately, theres no way to "hard" stop Sun sun4u CPUs or emulate some NMI short of triggering a red state exception, which is rather hairy to recover from. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110622100524.GO14797>