Steve Deiters wrote: >> Yes, that's expected: If gettimeofday runs syscall-less, it >> tries to read the time offset from a page which the Linux >> kernel updates regularly. When user-space detects an ongoing >> update, it spins until that has completed. But as Xenomai >> runs the task with higher priority than the Linux update >> handler, you just ran into a live-lock. >> >> Switching on the Xenomai watchdog will confirm this: It will >> shoot that task, and the system will recover. >> >> Jan >> >> -- >> Siemens AG, Corporate Technology, CT T DE IT 1 Corporate >> Competence Center Embedded Linux >> > > I'm not all too familiar with the time handling in the kernel. If you > have any refernces that help me better follow your explanation that > would be appreciated. > > If you linked against the POSIX skin it would then seem there is no safe > way of calling gettimeofday. Even starting from main in this case is a > real time task. In this case I would think that gettimeofday should be > either wrapped to force a mode change before calling > __real_gettimeofday, or should somehow be expressly forbidden.
The reason why I did not wrap gettimeofday is that we already have a wrapped clock_gettime, which is the newer service supposed to be used by real-time applications. If you are not porting a non real-time application, there is no reason to use gettimeofday, and if you are, this guide: http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Timing_services. Should explain you what you need to do. -- Gilles. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
