1*abb0f93cSkardel Bug Id: 4023118 2*abb0f93cSkardel Category: kernel 3*abb0f93cSkardel Subcategory: other 4*abb0f93cSkardel State: integrated 5*abb0f93cSkardel Synopsis: sun4u doesn't keep accurate time 6*abb0f93cSkardel Description: 7*abb0f93cSkardel 8*abb0f93cSkardel[ bmc, 12/20/96 ] 9*abb0f93cSkardel 10*abb0f93cSkardelThe clock on a sun4u drifts unacceptably. On a typical 143 mHz Ultra, 11*abb0f93cSkardelthe clock took 1.0001350 seconds to count 1 second. While this may seem 12*abb0f93cSkardeltrivial, it adds up quickly. In this case, the TOD chip will have to 13*abb0f93cSkardelpull the clock forward by 2 seconds every 4 hours and 7 minutes. 14*abb0f93cSkardelThis drift rate is so high, that the clock is close to being too broken 15*abb0f93cSkardelfor NTP to guarantee correctness (in order for NTP's mechanism to work, 16*abb0f93cSkardelit must be assured that the local clock drifts no more than 20 ms in 64 17*abb0f93cSkardelseconds; this particular 143 mHz Ultra will drift by nearly 9 ms in that 18*abb0f93cSkardelperiod). This problem has been reproduced on virtually all sun4u 19*abb0f93cSkardelclasses. 20*abb0f93cSkardel 21*abb0f93cSkardelThe fundamental problem lies in the kernel's perception of ticks per 22*abb0f93cSkardelsecond. The PROM is responsible for determining this figure exactly, 23*abb0f93cSkardeland the kernel extracts it into the variable cpu_tick_freq. On sun4u's, 24*abb0f93cSkardelthis number is disconcertingly round: 143000000, 167000000, 248000000, 25*abb0f93cSkardeletc. Indeed, a simple experiment revealed that these numbers were 26*abb0f93cSkardelquite far from the actual ticks per second. Typical was the 143 mHz 27*abb0f93cSkardelUltra which was discovered to tick around 142,980,806 (+/- 10) times 28*abb0f93cSkardelper second. 29*abb0f93cSkardel 30*abb0f93cSkardel Work around: 31*abb0f93cSkardel 32*abb0f93cSkardel Integrated in releases: s297_27 33*abb0f93cSkardel Duplicate of: 34*abb0f93cSkardel Patch id: 35*abb0f93cSkardel See also: 36*abb0f93cSkardel Summary: 37