Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Jeroen Van den Keybus wrote:
>  > > Gilles,
>  > > 
>  > > 
>  > > I cannot reproduce those messages after turning nucleus debugging on.
>  > > Instead, I now either get relatively more failing mutexes or even hard
>  > > lockups with the test program I sent to you. If the computer didn't 
> crash,
>  > > dmesg contains 3 Xenomai messages relating to a task being movend to
>  > > secondary domain after exception #14. As when the computer crashes: I 
> have
>  > > written the last kernel panic message on a paper. Please tell if you want
>  > > also the addresses or (part of) the call stack.
>  > > 
>  > > I'm still wondering if there's a programming error in the mutex test
>  > > program. After I sent my previous message, and before I turned nucleus
>  > > debugging on, I managed (by reducing the sleeptimes to max. 5.0e4) to
>  > > fatally crash the computer, while spewing out countless 'scheduling while
>  > > atomic messages'. Is the mutex error reproducible ?
>  > 
>  > I was not able to crash my box or generate that scheduler warnings, but
>  > the attached patch fixes the false positive warnings of unlocked
>  > mutexes. We had a "leak" in the unlock path when someone was already
>  > waiting. Anyway, *this* issues should not have caused any other problems
>  > then the wrong report of rt_mutex_inquire().
> 
> Actually the patch seem insufficient, the whole block :
>       {
>       xnsynch_set_owner(&mutex->synch_base,&task->thread_base);
>       mutex->owner = task;
>       mutex->lockcnt = 1;
>       goto unlock_and_exit;
>       }
> 
> should be done after xnsynch_sleep_on in rt_mutex_lock.
> 

Damn, of course - except for "mutex->owner = task". Then this missing
xnsync_set_owner() may have caused serious issues? Will test...

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to