Problem with clock setting

[Joel Sherrill]

Lars Törnkvist wrote:
>
>
>   
>> -----Original Message-----
>> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com] 
>>
>> Lars Törnkvist wrote:
>>     
>>> Hi,
>>>
>>> Recently we started using the clock manager. When we set 
>>>       
>> the clock forward in time a peculiar thing happen, the system 
>> will "freeze" for a while and then start working again. The 
>> time it freezes is direct linear to the amount of time we 
>> step forward, for each hour there will be about 30 seconds of 
>> "freezing". Since the clock is correct after the "freeze" 
>> period (the 30 secs hasn't disappeared) RTEMS obviously 
>> doesn't freeze, the system just becomes unresponsive. 
>>     
>>> Is this the way its supposed to be or have we done 
>>>       
>> something wrong or forgotten something? Is there a way to 
>> avoid this "freeze" thing?
>>     
>>>   
>>>       
>> When the clock is adjusted forward, any events scheduled to 
>> fire must be processed.  If there were no events on the 
>> Seconds watchdog chain, then it should take 0 time to 
>> execute.  The list of scheduled activities is adjusted 
>> forward in chunks based upon how long each pending event has left.
>>
>> I assume you have a lot of time based events which are 
>> triggered by the time change.  Check out the source in 
>> cpukit/score/src/watchdogadjust.c. 
>>
>> It looks like if there is an adjustment which empties the 
>> chain, the loop breaks. 
>>
>> Please confirm if you do or don't have a lot of activities 
>> scheduled based upon wall-time. 
>>     
>
> Since I don't know the exact definition of wall-time I won't try to answer you directly, but I can tell you what our application does. First, our application have been up and running about a year without the clock manager. 
>
>   
Wall time is what you read on a clock as opposed to interval time which 
is in ticks.
> We have about 20 tasks running. Five of them loops over a message receive call with timeout. Two with 1000 ms timeout, tvo with 100 ms timeout and one with 10 ms timeout. All other tasks, except for two, are waiting forever for an event or a message. The two exceptions are the init task and the Timer server.
>
> There are about 10 queues in use.
>
> We also use a few timers (obviously with the timer server), but only one or two are active at the same time. The main reason, for now, for the use of the clock manager is for one of these timers. We want to be able to trigger something at night. Nothing else in our application cares about what date or time it is.
>
> I have adjusted the clock forward both with and without the date/time aware timer. No difference whatsoever. The 30 secs/hour forward is still there. 
>
> Do tell me if you need more information.
>   

Do you have a test case I could play with?  It sounds like a possible 
bug and I want to look at it
in more detail.

--joel
> Thanks
> Lars Törnkvist
> Solid Software AB
>
>   
>>> We are running RTEMS 4.6.6 on a Coldfire system and it 
>>>       
>> works fine otherwise.
>>