Native preemption is the culprit [was Re: today's CURRENT lockups]

[Jon Noack]

On 07/10/04 02:06, Ariff Abdullah wrote:
> On Sat, 10 Jul 2004 01:18:06 -0400 (EDT)
> Robert Watson <rwatson at freebsd.org> wrote:
>> FYI, UP+SCHED_ULE with PREEMPTION hung within three seconds of 
>> starting the benchmark. Without PREEMPTION it seems to run fine.
>> 
>> So it looks like either PREEMPTION has a problem, or it's
>> triggering an existing problem elsewhere. If it's only one problem,
>> it seems not to depend on either SMP/UP or the scheduler choice. If
>> it's multiple problems, who knows :-). As the MySQL test relies on 
>> threading, we could be looking at an edge case involving threading 
>> and scheduling/preemption-- the other reports I've seen mention 
>> X11/KDE, which would also involve threading. On the other hand, it 
>> could just be load. Tomorrow I'll load up a box with non-threaded 
>> apps and see what happens.
> 
> I'm suspecting bad combination between threaded apps and current
> native preemption, either the preemption itself, or threads. Running
> current kernel without any threaded apps turns up nothing suspicious.
> Once the threaded apps started, it's like sending the entire system to
> the death row.
> 
> I'm reverting following files to pre-July 2 to achive solid stability:
> 
>  sys/sys/interrupt.h          - v1.27
>  sys/kern/kern_intr.c         - v1.110
>  sys/i386/i386/intr_machdep.c - v1.6
>  sys/kern/sched_ule.c         - v1.109

Note that I haven't run across any issues after just reverting 
sys/kern/sched_ule.c to rev. 1.113.  The same workload (X11/KDE/etc.) 
that crashes native preemption quite quickly has been running solidly 
for over 14 hours now.

Jon