In message: <45889598.3030408_at_u.washington.edu> Garrett Cooper <youshi10_at_u.washington.edu> writes: : Scot Hetzel wrote: : > On 12/19/06, Mark Kirkwood <markir_at_paradise.net.nz> wrote: : >> Mark Kirkwood wrote: : >> : >> > Just tried out this on 6-STABLE : >> : >> > I can't get the hang at all (with or without thee extra includes): : >> > : >> > # time ./settimetest : >> > INFO: Saved current time : >> > INFO: settimeofday completed sucessfully : >> > INFO: Reset time to original value : >> > 0.000u 0.002s 0:00.00 0.0% 0+0k 0+0io 0pf+0w : >> > : >> : >> Oops - thought I was reading -stable instead of -current list : >> (doh).. sorry! Well at least you know it can work on *some* version of : >> FreeBSD!....(I don't have any machines running -current at the moment to : >> test). : >> : > : > Here's the time for the test on FreeBSD/amd64 -CURRENT, update yesterday. : > : > hp010# date ; time ./t1 ; date : > Tue Dec 19 19:07:33 CST 2006 : > INFO: Saved current time : > INFO: settimeofday completed sucessfully : > INFO: Reset time to original value : > 0.000u 1469.241s 0:00.00 0.0% 5+175k 0+0io 0pf+0w : > Tue Dec 19 19:07:33 CST 2006 : > hp010# date 200612191933 : > Tue Dec 19 19:33:00 CST 2006 : > : > Scot : Well, I'll find a random unused machine, setup FreeBSD on it with vmware : and then try that out. Seems interesting that it takes 30 minutes to run : instead of being done almost instantaneously. It does run almost instantly if you use a time from 2000. The date command also causes the lockup if you say 'date 1970010100140' as well. Looks like there's a loop in the kernel to do division, but I can't quite find where it is. If you have a good test setup, maybe you can do a binary search in the settimeofday code to find why a large leap backwards causes problems. WarnerReceived on Thu Dec 21 2006 - 10:15:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:04 UTC