panic: APIC: Previous IPI is stuck

Andy Farkas andy at
Tue Oct 5 14:34:01 PDT 2004

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).


More information about the freebsd-current mailing list