From owner-freebsd-current@FreeBSD.ORG Fri Jul 2 18:57:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50DA8106567B; Fri, 2 Jul 2010 18:57:45 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6B18FC08; Fri, 2 Jul 2010 18:57:44 +0000 (UTC) Received: by fxm13 with SMTP id 13so2896616fxm.13 for ; Fri, 02 Jul 2010 11:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=5A4fhnvF67HRcTd6VKJiAWaj06i5vK+yzOxl3ewacAk=; b=hnkt5W9AMO5SRrQGGmqZrpnFV1ooWYLfI2sKRuA+8aCqn224HOweHeL4nwqZSd8/p3 gD5aGR6kxTLV8wG2q90/DwrVmUV9lNH+8fo3yyINVQqVuH7FWvlASUz4uHFzp1A6URNl YqSyrDift5JhBQ6RT7cCmejeLJjozTKbe1kPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=CN1hJHYv9WgoblKpPIfta7lMNhyYC1MGszmmyVUvrt0cLKpv0HF/bUHMpftZpOedVZ AG10+rs9DvZJnkDYna43fIncdCzwW/FWwoFZoHKTXvCSWSGjL/zi1r62zHTVVLFPi11B IdyNxzEtqvnF0IaIEIsFEjd3pQR368r4kw42w= Received: by 10.223.117.65 with SMTP id p1mr1225988faq.76.1278097059742; Fri, 02 Jul 2010 11:57:39 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id b18sm2102921fab.35.2010.07.02.11.57.38 (version=SSLv3 cipher=RC4-MD5); Fri, 02 Jul 2010 11:57:39 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C2E36A0.8040405@FreeBSD.org> Date: Fri, 02 Jul 2010 21:57:36 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Sean Bruno References: <4C2267FA.9010909@FreeBSD.org> <1277326405.2478.33.camel@localhost.localdomain> <1278094976.2469.27.camel@localhost.localdomain> In-Reply-To: <1278094976.2469.27.camel@localhost.localdomain> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "sbruno@freebsd.org" , FreeBSD-Current Subject: Re: No issues, just informative QEMU boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 18:57:45 -0000 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