Date: Mon, 04 Oct 2004 12:42:53 -0700 From: Julian Elischer <julian@elischer.org> To: Peter Holm <peter@holm.cc> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: scheduler (sched_4bsd) questions Message-ID: <4161A7BD.3040706@elischer.org> In-Reply-To: <20041004191410.GA8423@peter.osted.lan> 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> <41619D29.1000704@elischer.org> <20041004191410.GA8423@peter.osted.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
ok, then if it happens again, from ddb, run
show ktr
after you've done the 'ps' and go back a couple of hundred events..
thanks.
Peter Holm wrote:
>On Mon, Oct 04, 2004 at 11:57:45AM -0700, Julian Elischer wrote:
>
>
>>can you run ktrdump against teh corefile and get the ktr output?
>>(you do have it enabled right?)
>>
>>
>>
>
>No, that's one of the problems: doadump() fails with this specific panic.
>
>- Peter
>
>
>
>>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"
>>>
>>>
>>>
>>>
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4161A7BD.3040706>