Re: [Xenomai-core] Potential problem with rt_eepro100

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

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

Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
> 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.

But that is nucleus business, nothing skins can screw up (as long as
they do not misuse APIs).

> 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 still see no benefit in this check. Where to you want to place the bit
set? Aren't that just the same locations where
xnsched_set_[self_]resched already is today?

But maybe you can provide some motivating bug scenarios, real ones of
the past or realistic ones of the future.

Jan


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