Re: [Xenomai-core] Scheduling while atomic

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

Jan Kiszka wrote:
> 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...

Correction: xnsynch_wakeup_one_sleeper() updates synch->owner, so all
fine with my patch in this regard. I guess it is really some migration
issue again.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]