From owner-freebsd-arch@FreeBSD.ORG Mon Oct 4 18:57:46 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E19E16A4CE for ; Mon, 4 Oct 2004 18:57:46 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0040243D3F for ; Mon, 4 Oct 2004 18:57:45 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id D48557A403; Mon, 4 Oct 2004 11:57:45 -0700 (PDT) Message-ID: <41619D29.1000704@elischer.org> Date: Mon, 04 Oct 2004 11:57:45 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Peter Holm References: <1095468747.31297.241.camel@palm.tree.com> <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> <20041004184939.GA8178@peter.osted.lan> In-Reply-To: <20041004184939.GA8178@peter.osted.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "freebsd-arch@freebsd.org" cc: Stephan Uphoff Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 18:57:46 -0000 can you run ktrdump against teh corefile and get the ktr output? (you do have it enabled right?) Peter Holm wrote: >On Mon, Oct 04, 2004 at 01:34:38PM -0400, Stephan Uphoff wrote: > > >>On Mon, 2004-10-04 at 11:31, John Baldwin wrote: >> >> >>>On Friday 01 October 2004 12:13 am, Stephan Uphoff wrote: >>> >>> >>>>On Wed, 2004-09-29 at 18:14, Stephan Uphoff wrote: >>>> >>>> >>>>>I was looking at the MUTEX_WAKE_ALL undefined case when I used the >>>>>critical section for turnstile_claim(). >>>>>However there are bigger problems with MUTEX_WAKE_ALL undefined >>>>>so you are right - the critical section for turnstile_claim is pretty >>>>>useless. >>>>> >>>>> >>>>Arghhh !!! >>>> >>>>MUTEX_WAKE_ALL is NOT an option in GENERIC. >>>>I recall verifying that it is defined twice. Guess I must have looked at >>>>the wrong source tree :-( >>>>This means yes - we have bigger problems! >>>> >>>>Example: >>>> >>>>Thread A holds a mutex x contested by Thread B and C and has priority >>>>pri(A). >>>> >>>>Thread C holds a mutex y and pri(B) < pri(C) >>>> >>>>Thread A releases the lock wakes thread B but lets C on the turnstile >>>>wait queue. >>>> >>>>An interrupt thread I tries to lock mutex y owned by C. >>>> >>>>However priority inheritance does not work since B needs to run first to >>>>take ownership of the lock. >>>> >>>>I is blocked :-( >>>> >>>> >>>Ermm, if the interrupt happens after x is released then I's priority should >>>propagate from I to C to B. >>> >>> >>There is a hole after the mutex x is released by A - but before B can >>claim the mutex. The turnstile for mutex x is unowned and interrupt >>thread I when trying to donate its priority will run into: >> >> if (td == NULL) { >> /* >> * This really isn't quite right. Really >> * ought to bump priority of thread that >> * next acquires the lock. >> */ >> return; >> } >> >>So B needs to run and acquire the mutex before priority inheritance >>works again and does not get a priority boost to do so. >> >>This is easy to fix and MUTEX_WAKE_ALL can be removed again at that time >>- but my time budget is limited and Peter has an interesting bug left >>that has priority. >> >> > >I'm not closer to being able to create this panic in a controlled way. >After a whole day of different tests I finally got this panic: >http://www.holm.cc/stress/log/cons81.html. The trigger seems to be one >particular Java applet, but it is not easily reproduceable. > >- Peter > > > >>>If the interrupt happens before x is released, >>>then the final bit of propagate_priority() should handle it since it resorts >>>the turnstile's thread queue so that C will be awakened rather than B. >>> >>> >>Agreed. >> >> Stephan >> >> >_______________________________________________ >freebsd-arch@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > >