Re: PI BUG with -rt13

[david singleton <dsingleton@mvista.com>]

On Nov 24, 2005, at 12:32 PM, Dinakar Guniguntala wrote:

> On Fri, Nov 25, 2005 at 01:56:37AM +0530, Dinakar Guniguntala wrote:
> > On Thu, Nov 24, 2005 at 03:57:34PM +0100, Ingo Molnar wrote:
> > > * david singleton <dsingleton@mvista.com> wrote:
> > >
> > > > Sure.  Attached is the locking fix patch. [...]
> > >
> > > thanks, applied - it should show up in -rt15.
> >
> > I just noticed with the above fix, Paul's testcase completely
> > hangs up and when killed I hit the BUG mentioned below.
> > Till -rt13, this testcase just ran to completion
>
> Forgot to mention that I notice the same failure with -rt15 as well

Good news and bad news.

Good news.  This test doesn't exercise the robust futex code.

Pthread mutexes that want priority queuing, priority inheritance and/or 
robustness
must have either  the robust (PTHREAD_MUTEX_ROBUST_NP) attribute set
and/or the PTHREAD_PRIO_INHERIT attribute set at mutex creation time.

e.g.
pthread_mutexattr_setrobust_np (&mutex_attr, PTHREAD_MUTEX_ROBUST_NP);

pthread_mutexattr_setprotocol(&state->mutex_attr, PTHREAD_PRIO_INHERIT);

pthread_mutexes that don't have either of  these attributes set on the 
pthread_mutex
will exercise the original futex code.

Now a question before the bad news,    Are you in the OOM path when you
think the system is hung?  What does 'top' say about freemem and 
available
and used swap space?

If you are not in the OOM path then the bad news is this looks like an 
SMP timer
problem.

David

> 	-Dinakar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/