Date: Wed, 6 Oct 2004 07:12:27 +1000 (EST) From: Andy Farkas <andy@bradfieldprichard.com.au> To: Brian Fundakowski Feldman <green@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: panic: APIC: Previous IPI is stuck Message-ID: <20041006064726.W35438@bpgate.speednet.com.au> In-Reply-To: <20041003075303.GG1034@green.homeunix.org> References: <20040924230425.GB1164@green.homeunix.org> <200409271635.44017.jhb@FreeBSD.org> <20041003075303.GG1034@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 3 Oct 2004, Brian Fundakowski Feldman wrote: > On Sat, Oct 02, 2004 at 02:02:01AM -0400, Brian Fundakowski Feldman wrote: >> Okay, I just got another one of these, exactly the same as that one but >> for the fact that the softclock() interrupt was specifically locking >> Giant instead of the interrupt thread loop. So the other CPU owned >> Giant at the time and the scheduling CPU is trying to acquire it and >> interrupted by needing to run the statclock(). >> >> This is way too coincidental to ignore. >> >> SCHED_ULE is far too complex for me to understand much of right now; >> what prevents sched_clock() from calling kseq_assign() multiple times >> per CPU? Are we _absolutely_100%_certain_ that functionality works >> correctly? > > Ping... adding Jeff... I really wish I understood SCHED_ULE, because it > seems entirely plausible it's trying to send two IPIs, the first of > which would get blocked waiting for the held sched_lock, and the second > of which would never have its interrupt serviced because the first one > blocked on sched_lock would have interrupts disabled and would remain > unable to respond to an IPI... I can confirm that 5.3-BETA7 with SCHED_4BSD is rock solid, but with SCHED_ULE a panic is easily triggered (by make -j4 buildworld). -andyf
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041006064726.W35438>