Re: [Xenomai-core] Potential problem with rt_eepro100

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Jan Kiszka wrote:
>>> At first sight, here you are more breaking things than cleaning them.
>> Still, it has the SMP record for my test program, still runs with ftrace 
>> on (after 2 hours, where it previously failed after maximum 23 minutes).
> 
> My version was indeed still buggy, I'm reworking it ATM.
> 
>> If I get the gist of Jan's changes, they are (using the IPI to transfer 
>> one bit of information: your cpu needs to reschedule):
>>
>> xnsched_set_resched:
>> -      setbits((__sched__)->status, XNRESCHED);
>>
>> xnpod_schedule_handler:
>> +	xnsched_set_resched(sched);
>> 	
>> If you (we?) decide to keep the debug checks, under what circumstances 
>> would the current check trigger (in laymans language, that I'll be able 
>> to understand)?
> 
> That's actually what /me is wondering as well. I do not see yet how you
> can reliably detect a missed reschedule reliably (that was the purpose
> of the debug check) given the racy nature between signaling resched and
> processing the resched hints.

The purpose of the debugging change is to detect a change of the
scheduler state which was not followed by setting the XNRESCHED bit.
Getting it to work is relatively simple: we add a "scheduler change set
remotely" bit to the sched structure which is NOT in the status bit, set
this bit when changing a remote sched (under nklock). In the debug check
code, if the scheduler state changed, and the XNRESCHED bit is not set,
only consider this a but if this new bit is not set. All this is
compiled out if the debug is not enabled.

I will try and work on this this week-end.

-- 
                                                                Gilles.