[Xenomai-core] Fixed two timer base regressions

[Xenomai-core] Fixed two timer base regressions

[Jan Kiszka]

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

Hi Philippe,

the "trivial" bugs are fixed already: see #2152 for the reason why
rt_dev_read timeouts took too long (the timer mode was ignored by
xnsynch_sleep_on), and I also found a yet invisible bug in
rtdm_toseq_init that would have picked the wrong time base (#2153).

Now just that rtcanrecv issue remains...

Jan


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

[Xenomai-core] Re: Fixed two timer base regressions

[Philippe Gerum]

On Thu, 2007-02-08 at 09:38 +0100, Jan Kiszka wrote:
> Hi Philippe,
> 
> the "trivial" bugs are fixed already: see #2152 for the reason why
> rt_dev_read timeouts took too long (the timer mode was ignored by
> xnsynch_sleep_on),

Ok.

>  and I also found a yet invisible bug in
> rtdm_toseq_init that would have picked the wrong time base (#2153).
> 

Using xnpod_current_thread()'s time base in rtdm_toseq_init() will
always pick the master one when called over a secondary mode context,
which according to the doc, is allowed. Is this intended?

> Now just that rtcanrecv issue remains...
> 
> Jan
> 
-- 
Philippe.

[Xenomai-core] Re: Fixed two timer base regressions

[Jan Kiszka]

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

Philippe Gerum wrote:
> On Thu, 2007-02-08 at 09:38 +0100, Jan Kiszka wrote:
>> Hi Philippe,
>>
>> the "trivial" bugs are fixed already: see #2152 for the reason why
>> rt_dev_read timeouts took too long (the timer mode was ignored by
>> xnsynch_sleep_on),
> 
> Ok.
> 
>>  and I also found a yet invisible bug in
>> rtdm_toseq_init that would have picked the wrong time base (#2153).
>>
> 
> Using xnpod_current_thread()'s time base in rtdm_toseq_init() will
> always pick the master one when called over a secondary mode context,
> which according to the doc, is allowed. Is this intended?

rtdm_toseq_init will only be called over primary context, it belongs
into the same context as rtdm_mutex_timedlock, rtdm_sem_timeddown, etc.


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

Re: [Xenomai-core] Re: Fixed two timer base regressions

[Jan Kiszka]

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

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> On Thu, 2007-02-08 at 09:38 +0100, Jan Kiszka wrote:
>>> Hi Philippe,
>>>
>>> the "trivial" bugs are fixed already: see #2152 for the reason why
>>> rt_dev_read timeouts took too long (the timer mode was ignored by
>>> xnsynch_sleep_on),
>> Ok.
>>
>>>  and I also found a yet invisible bug in
>>> rtdm_toseq_init that would have picked the wrong time base (#2153).
>>>
>> Using xnpod_current_thread()'s time base in rtdm_toseq_init() will
>> always pick the master one when called over a secondary mode context,
>> which according to the doc, is allowed. Is this intended?
> 
> rtdm_toseq_init will only be called over primary context, it belongs
> into the same context as rtdm_mutex_timedlock, rtdm_sem_timeddown, etc.
> 

OK, got your point: you were referring to the rtdm_toseq_init doc which
talks about secondary mode usage - this needs fixing now (and never made
any sense :( ).

Jan


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

[Xenomai-core] Re: Fixed two timer base regressions

[Philippe Gerum]

On Thu, 2007-02-08 at 10:21 +0100, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Thu, 2007-02-08 at 09:38 +0100, Jan Kiszka wrote:
> >> Hi Philippe,
> >>
> >> the "trivial" bugs are fixed already: see #2152 for the reason why
> >> rt_dev_read timeouts took too long (the timer mode was ignored by
> >> xnsynch_sleep_on),
> > 
> > Ok.
> > 
> >>  and I also found a yet invisible bug in
> >> rtdm_toseq_init that would have picked the wrong time base (#2153).
> >>
> > 
> > Using xnpod_current_thread()'s time base in rtdm_toseq_init() will
> > always pick the master one when called over a secondary mode context,
> > which according to the doc, is allowed. Is this intended?
> 
> rtdm_toseq_init will only be called over primary context, it belongs
> into the same context as rtdm_mutex_timedlock, rtdm_sem_timeddown, etc.
> 

So the doc needs fixing, I guess.

-- 
Philippe.