Date: Fri, 02 Jul 2010 21:57:36 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Sean Bruno <seanbru@yahoo-inc.com> Cc: "sbruno@freebsd.org" <sbruno@freebsd.org>, FreeBSD-Current <freebsd-current@freebsd.org> Subject: Re: No issues, just informative QEMU boot Message-ID: <4C2E36A0.8040405@FreeBSD.org> In-Reply-To: <1278094976.2469.27.camel@localhost.localdomain> References: <mailpost.1277313039.5009268.5872.mailing.freebsd.current@FreeBSD.cs.nctu.edu.tw> <4C2267FA.9010909@FreeBSD.org> <1277326405.2478.33.camel@localhost.localdomain> <1278094976.2469.27.camel@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C2E36A0.8040405>