* [Xenomai-core] Fixed two timer base regressions
@ 2007-02-08 8:38 Jan Kiszka
2007-02-08 9:18 ` [Xenomai-core] " Philippe Gerum
0 siblings, 1 reply; 5+ messages in thread
From: Jan Kiszka @ 2007-02-08 8:38 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Xenomai-core] Re: Fixed two timer base regressions
2007-02-08 8:38 [Xenomai-core] Fixed two timer base regressions Jan Kiszka
@ 2007-02-08 9:18 ` Philippe Gerum
2007-02-08 9:21 ` Jan Kiszka
0 siblings, 1 reply; 5+ messages in thread
From: Philippe Gerum @ 2007-02-08 9:18 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Xenomai-core] Re: Fixed two timer base regressions
2007-02-08 9:18 ` [Xenomai-core] " Philippe Gerum
@ 2007-02-08 9:21 ` Jan Kiszka
2007-02-08 9:27 ` Jan Kiszka
2007-02-08 9:30 ` Philippe Gerum
0 siblings, 2 replies; 5+ messages in thread
From: Jan Kiszka @ 2007-02-08 9:21 UTC (permalink / raw)
To: rpm; +Cc: xenomai-core
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-core] Re: Fixed two timer base regressions
2007-02-08 9:21 ` Jan Kiszka
@ 2007-02-08 9:27 ` Jan Kiszka
2007-02-08 9:30 ` Philippe Gerum
1 sibling, 0 replies; 5+ messages in thread
From: Jan Kiszka @ 2007-02-08 9:27 UTC (permalink / raw)
To: rpm; +Cc: xenomai-core
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Xenomai-core] Re: Fixed two timer base regressions
2007-02-08 9:21 ` Jan Kiszka
2007-02-08 9:27 ` Jan Kiszka
@ 2007-02-08 9:30 ` Philippe Gerum
1 sibling, 0 replies; 5+ messages in thread
From: Philippe Gerum @ 2007-02-08 9:30 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-02-08 9:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-08 8:38 [Xenomai-core] Fixed two timer base regressions Jan Kiszka
2007-02-08 9:18 ` [Xenomai-core] " Philippe Gerum
2007-02-08 9:21 ` Jan Kiszka
2007-02-08 9:27 ` Jan Kiszka
2007-02-08 9:30 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.