Steve Deiters wrote: >> Periodically setting the time is risky if timed jobs depend >> on Xenomai's real-time clock - it may jump in all directions... >> >>> Any other suggestions for providing timestamps to real time >> tasks in >>> this case? >> Do you just need precise timestamps from with real-time >> tasks, or do you have to synchronize timer events of the >> Xenomai core on an external clock? >> >> For the former case (precisely our scenario), we laid the >> ground to extend Xenomai 2.5 with RT-safe syscalls to obtain >> Linux's view on gettimeofday. It "just" needs some polishing >> to post this for upstream. >> Wolfgang (CC'ed) is working on this. > > I'm just looking to get timestamps in the real time task. At least in > my case being able to call gettimeofday from the real time thread would > be exactly what I need. > > By the way, calling gettimeofday currently within a real time thread > seems to occasionally freeze up my whole system. I was going to make > another post for this after I got a chance to verify some details. Has > anyone noticed anything similar to this? >
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 _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
