> Klaas Gadeyne wrote: >> I've noticed that threads which, in my ignorant opinion, are supposed >> to be sleeping, get woken up much earlier than I expect them to be. >> >> Please find attached a modified version of the trivial-periodic.c >> application, which creates a RT_TASK that should sleep as long as >> possible (i.e. until unblocked by a signal handler). However, the >> task gets woken up much earlier (and many times) _before_ that time it >> seems. >> >> head /tmp/app.txt >> current_time = 1207928393295939429 >> sleep until 18446744073709551615 >> [TIMERLOOP] Total errors = 1, return code = -110 >> current_time = 1207928393296000379 >> sleep until 18446744073709551615 >> [TIMERLOOP] Total errors = 2, return code = -110 >> current_time = 1207928393296005409 >> sleep until 18446744073709551615 >> [TIMERLOOP] Total errors = 3, return code = -110 >> current_time = 1207928393296009604 >> >> What did I overlook here? > > Probably an overflow issue: (RTIME)~0 will be converted to TSCs, and if > your box runs at > 1GHZ, the result of this conversion will by something > < (RTIME)~0 due to the overflow. And this can result in an absolute > timeout date (in TSC units) before the current date -> ETIMEDOUT. Can > you confirm this?
I have no linux box at hand, but I noticed that [*] xntimer_do_start_aperiodic() passes its xnticks_t interval argument (which is an unsigned long long) to xnarch_ns_to_tsc, and that one expects a (signed) long long. If I did not make any calculation errors (a very small chance...) in "my" case "interval" > LLONG_MAX so there's already an overflow there. More on monday. Thx! Klaas [*] <http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/timer.c?v=SVN-2.3.x#095> <http://www.rts.uni-hannover.de/xenomai/lxr/source/include/asm-generic/system.h?v=SVN-2.3.x#174> _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
