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
signature.asc
Description: OpenPGP digital signature