Ciao Philippe! Philippe Gerum wrote:
Hannes Mayer wrote:Hi all! I was just wondering if calling do_gettimeofday in an ADEOS interrupt handler might cause any problems whatsoever ? My ISR: flags = adeos_critical_enter (NULL); [...] do_gettimeofday() [...] adeos_critical_exit (flags); I saw that the code for do_gettimeofday is different in kernel 2.4 and kernel 2.6: Kernel 2.4: void do_gettimeofday(struct timeval *tv) { [...] read_lock_irqsave(&xtime_lock, flags); [...] read_unlock_irqrestore(&xtime_lock, flags); Kernel 2.6: void do_gettimeofday(struct timeval *tv) { [...] do { [...] seq = read_seqbegin(&xtime_lock); [...] } while (read_seqretry(&xtime_lock, seq)); Well, read_lock_irqsave in 2.4 looks like a possible source for trouble, while read_seqbegin in 2.6 doesn't do anything with interrupts, right ?Yes, but that's not better anyway. Imagine what would happen if an undergoing write sequence on the xtime_lock in the Linux domain was preempted by an ISR from a higher priority domain which in turn calls do_gettimeofday(): the read sequence running over your high priority ISR would then loop on read_seqretry(), waiting for the undergoing write to end. Problem is, that the undergoing write sequence would not be allowed to resume until your current high priority domain running do_gettimeofday() relinquishes the processor. Catch 22. This could happen in both UP and SMP configs, not to speak of the funky behaviour one would get with the additional spinlock recursion issue over SMP, since a write sequence also grabs a spinlock.
Late "thank you"! Sorry! Was ill, but now I'm doing better. So do_gettimeofday is out of question... What would you suggest to do to get absolute time in RT context ? I'd be more than happy if you'd have a few pointers for me. Thanks a lot & best regards, Hannes.
