On Fri, Feb 5, 2010 at 8:19 AM, Garrett Cooper <[email protected]> wrote: > On Thu, Feb 4, 2010 at 10:27 PM, Mitani <[email protected]> wrote: >> Hi, >> >> I noticed that "stime01" test let system-clock be faster than right time. >> >> "stime01.c" is going to set system-clock by calling "stime()" function >> with "new_time" variable. >> It gets "curr_time" by "time()" function, and sets "curr_time + 10sec" >> in "new_time". >> But after the test, It doesn't restore system-clock. >> >> Therefore, system-clock is set faster than right time about 10 seconds >> after "stime01" test. >> If this test is repeated many times, the system-clock advances for the >> number of test times. >> And, if system is rebooted, hardware-clock will be wrong. >> >> How about following patch? > > The patch looks good, but I assume (and hope) that cleanup gets > executed every time before the program exits?
Err... two other problems with the above code now that I look at it a bit closer... 1. tst_brkm in cleanup shouldn't have cleanup as the second arg; I'm not sure whether or not tst_brkm handles infinite recursion properly; NULL should be the second arg (if you don't want to exit) or tst_exit (if you do want to exit). 2. What happens if you try to restore the time and it failed to get the original time (shouldn't happen, but it can happen if the RTC driver is busted, like it was on the cavium image that I was using at my previous job)? Thanks, -Garrett ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
