scheduler (sched_4bsd) questions

[Peter Holm]

On Sat, Oct 02, 2004 at 07:44:11PM -0700, Julian Elischer wrote:
> Stephan Uphoff wrote:
> >On Sat, 2004-10-02 at 14:31, Peter Holm wrote:
> >

I have now stress tested for more than 16 hours without seeing any freezes.
This is *good* news.

However, I did get a panic. I'll try to recreate it and hopefully get a dump:

kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x14c
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0618ade
stack pointer           = 0x10:0xcfcbabfc
frame pointer           = 0x10:0xcfcbac0c
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 30600 (java_vm)
[thread 100801]
Stopped at      sched_add+0x16: movl    0x14c(%esi),%ebx
db> where
sched_add(0,0) at sched_add+0x16
setrunqueue(c3545a80,0,c181ca80,c3545a80,cfcbac54) at setrunqueue+0x199
sched_wakeup(c3545a80) at sched_wakeup+0x43
setrunnable(c3545a80,c3545a80,cfcbac78,cfcbac8c,c0625cbf) at setrunnable+0x92
sleepq_resume_thread(c3545a80,ffffffff) at sleepq_resume_thread+0x82
sleepq_broadcast(c370be40,0,ffffffff,cfcbaccc,c05fae01) at sleepq_broadcast+0xf7
wakeup(c370be40) at wakeup+0xf
thread_userret(c1a93d80,cfcbad48) at thread_userret+0x121
userret(c1a93d80,cfcbad48,1,3,1) at userret+0x57
syscall(837002f,80d002f,bf69002f,8215000,2850c6e0) at syscall+0x2d9
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280e667f, esp = 0xbf8e5b50, ebp = 0xbf8e5b7c ---
db> call doadump
Dumping 255 MB
panic: blockable sleep lock (sleep mutex) taskqueue @ kern/subr_taskqueue.c:132
cpuid = 0
Uptime: 16h5m17s

(kgdb) l *0xc0618ade
0xc0618ade is in sched_add (../../../kern/sched_4bsd.c:960).
955     #ifdef SMP
956             int forwarded = 0;
957             int cpu;
958     #endif
959
960             ke = td->td_kse;
961             mtx_assert(&sched_lock, MA_OWNED);
962             KASSERT(ke->ke_state != KES_ONRUNQ,
963                 ("sched_add: kse %p (%s) already in run queue", ke,
964                 ke->ke_proc->p_comm));


> >>OK, right now I'm testing with all of Stephan's patches + the 
> >>MUTEX_WAKE_ALL flag. Uptime is 3 3/4 hour and looking good.
> 
> I've just resurfaced after a week of hell at work and home
> not BAD hell but more like "busy as hell".
> 
> I'm just integrating your fixes into my tree to understand what they do..
> expect more mail from me later.
> 
> >
> >
> >Great.
> >
> >Your attached diff contained all the fixes needed and I don't see the
> >need to post a cumulative patch. 
> >
> >The only thing left to do is migrate a critical sections from
> >kern_mutex.c to subr_turnstile.c for readability. 
> >(no functional changes)
> >
> >Maybe it would also better to just force  MUTEX_WAKE_ALL in
> >kern_mutex.c (#ifndef MUTEX_WAKE_ALL \n#define MUTEX_WAKE_ALL\n#endif)
> >to avoid temporary configuration file pollution?
> >
> >	Stephan
> >
> >

-- 
Peter Holm