Re: No issues, just informative QEMU boot

Sean Bruno wrote:
> On Wed, 2010-06-23 at 15:53 -0500, Sean Bruno wrote:
>> On Wed, 2010-06-23 at 15:00 -0500, Alexander Motin wrote:
>>> hint.atrtc.0.clock=0
>>> hint.attimer.0.clock=0
>>> hint.hpet.0.legacy_route=1
> 
> I've noted that the system is spitting out t_delta warnings on the
> console now.  The VM is 100% working, just wanted to know if this is a
> problem.
> 
> Trying to mount root from ufs:/dev/ad0s1a
> ct_to_ts([2010-07-02 18:11:34]) = 1278094294.000000000
> start_init: trying /sbin/init
> t_delta 15.feb043d4ae81c6e0 too short
> t_delta 16.01e5c61794458a00 too long
> t_delta 15.febf01dd932c7680 too short
> t_delta 16.01467be4eb29fba0 too long
> t_delta 16.0139723c1fef7f60 too long

Code printing this IMO broken since the beginning. AFAIU it was made to
guard hardclock precision. cpu_tick_calibrate() is expected to be called
every 16 seconds and it checks this interval using current system time
counter. But instead of simply dividing hardclock on 16*hz, which IMHO
would be reasonable for measuring it, it is called on first hardclock
tick of every 16'th second of the current time counter.

What you see here is a result of small irregular interrupt latency
jitter, when hardclock ticks just before or just after second boundary.
It causes cpu_tick_calibrate() to be called 1/hz second before or after
expected moment. When hz > 256 these messages are never logged, as 1/hz
mistake is less then maximum allowed by this function.

Except false positives this code IMO doesn't handles it's main purpose.
Even if hardclock run twice slower/faster, dependence on time counter's
16th second will most likely hide it.

I think this code should be either rewritten using divider or removed.

-- 
Alexander Motin