[Adeos-main] do_gettimeofday in ADEOS ISR

[Adeos-main] do_gettimeofday in ADEOS ISR

[Hannes Mayer]

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 ?

Thanks for all comments!

Best regards,
Hannes.

Re: [Adeos-main] do_gettimeofday in ADEOS ISR

[Philippe Gerum]

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.

-- 

Philippe.

Re: [Adeos-main] do_gettimeofday in ADEOS ISR

[Hannes Mayer]

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.

Re: [Adeos-main] do_gettimeofday in ADEOS ISR

[Philippe Gerum]

Hannes Mayer wrote:
> 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.

Since you cannot fiddle safely with Linux internals in RT context, I'd 
suggest you keep track of your RTOS's "epoch", saving Linux's count of 
jiffies and the current TSC when it boots, then each time you need the 
current date, convert the difference between the current TSC and the 
initial TSC to jiffies, and finally use the initial jiffy count as an 
offset to compute the real date.

-- 

Philippe.

Re: [Adeos-main] do_gettimeofday in ADEOS ISR

[Philippe Gerum]

Philippe Gerum wrote:
> Hannes Mayer wrote:
> 
>> 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.
> 
> 
> Since you cannot fiddle safely with Linux internals in RT context, I'd 
> suggest you keep track of your RTOS's "epoch", saving Linux's count of 
> jiffies and the current TSC when it boots, then each time you need the 
> current date, convert the difference between the current TSC and the 
> initial TSC to jiffies, and finally use the initial jiffy count as an 
> offset to compute the real date.
> 

Sidenote: this also means that using variable CPU freqs would be out of 
question, but doing so is not an option as soon as the RT support is 
required anyway, so I guess it would be ok.

-- 

Philippe.