settimeofday function taking 24 - 30 minutes to complete

[M. Warner Losh]

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. 

Warner