Date: Sun, 10 Oct 2004 16:07:55 -0400 From: Stephan Uphoff <ups@tree.com> To: Peter Holm <peter@holm.cc> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: scheduler (sched_4bsd) questions Message-ID: <1097438874.80398.12.camel@palm.tree.com> In-Reply-To: <20041010195758.GA52129@peter.osted.lan> References: <1096496057.3733.2163.camel@palm.tree.com> <1096603981.21577.195.camel@palm.tree.com> <200410041131.35387.jhb@FreeBSD.org> <1096911278.44307.17.camel@palm.tree.com> <41619D29.1000704@elischer.org><4161A7BD.3040706@elischer.org> <20041005130308.GA2586@peter.osted.lan> <1097437808.80398.4.camel@palm.tree.com> <20041010195758.GA52129@peter.osted.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2004-10-10 at 15:57, Peter Holm wrote: > On Sun, Oct 10, 2004 at 03:50:08PM -0400, Stephan Uphoff wrote: > > On Tue, 2004-10-05 at 09:03, Peter Holm wrote: > > > On Mon, Oct 04, 2004 at 12:42:53PM -0700, Julian Elischer wrote: > > > > > > OK, I got a crash dump now, after a few modifications to kern_shutdown.c > > > > > > There are however a few strange things worth noticing: > > > > > > 1) The are no panic string: > > > > > > Mounted root from ufs:/dev/ad0s1a. > > > pid 1146: corrected slot count (2->1) > > > [thread 100796] > > > Stopped at sched_add+0x13: movl 0x14c(%esi),%ebx > > > > > > 2) The gdb stack trace gets a bit weird at: > > > > > > #8 0xc07812da in calltrap () at ../../../i386/i386/exception.s:140 > > > #9 0xc05f0018 in flock (td=0x0, uap=0x0) at ../../../kern/kern_descrip.c:2138 > > > #10 0xc0619fd1 in setrunqueue (td=0xc2319180, flags=0x0) at kern_switch.c:521 > > > #11 0xc061921f in sched_wakeup (td=0xc2319180) at ../../../kern/sched_4bsd.c:859 > > > > > > Where did flock() come from? > > > > > > The full console output is at http://www.holm.cc/stress/log/cons82.html > > > > > > - Peter > > > > I am still puzzled. > > My newest pet theory is that the sorting of the kg_runq is corrupted > > before setrunqueue is called. > > Directly changing td_priority while the thread is on the run queue would > > be an explanation. > > However the only instance that I found is what I think is a rare > > condition where sleepq_resume_thread may be called while the thread is > > on a runqueue. (John - what did I miss this time ...) > > > > Peter could you try this patch? > > > > Sure, no problem. > > This patch + your previous changes applied to HEAD, right? > > - Peter Yes. I will try to clean up the old patches tonight to get them reviewed. Stephan > > > Index: subr_sleepqueue.c > > =================================================================== > > RCS file: /cvsroot/src/sys/kern/subr_sleepqueue.c,v > > retrieving revision 1.11 > > diff -u -r1.11 subr_sleepqueue.c > > --- subr_sleepqueue.c 19 Aug 2004 11:31:41 -0000 1.11 > > +++ subr_sleepqueue.c 10 Oct 2004 18:18:55 -0000 > > @@ -642,7 +642,7 @@ > > /* Adjust priority if requested. */ > > MPASS(pri == -1 || (pri >= PRI_MIN && pri <= PRI_MAX)); > > if (pri != -1 && td->td_priority > pri) > > - td->td_priority = pri; > > + sched_prio(td, pri); > > setrunnable(td); > > mtx_unlock_spin(&sched_lock); > > } > > > > Should it crash again could you walk the kg_runq to verify the sorting? > > > > Thanks > > Stephan > > > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1097438874.80398.12.camel>