[Xenomai-core] Re: Fixed two timer base regressions
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 mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: Fixed two timer base regressions
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. signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: Fixed two timer base regressions
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
