> 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. Even more of a problem is how I am supposed to know which calls are similar to this. I would expect I could call any Linux service without causing a deadlock/livelock situation, although in a nondeterministic manner. If I understood your explanation correctly, this is hanging whenever the Xenomai task tries to spin on the same lock as the kernel. However, I don't see how this is not a problem in general for acquiring any spinlock from a Xenomai task. I would expect once you introduce a priority based scheduler any spinlock becomes unsafe. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
