From patchwork Sat Sep 5 00:57:26 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 53150 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-lb0-f197.google.com (mail-lb0-f197.google.com [209.85.217.197]) by patches.linaro.org (Postfix) with ESMTPS id 2BD6322E23 for ; Sat, 5 Sep 2015 00:57:36 +0000 (UTC) Received: by lbcjc2 with SMTP id jc2sf11181126lbc.0 for ; Fri, 04 Sep 2015 17:57:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:mime-version:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:sender:precedence :list-id:x-original-sender:x-original-authentication-results :mailing-list:list-post:list-help:list-archive:list-unsubscribe; bh=EJMbFsBz+GQt78g5E13T57HNcTD4xJHAlZ7HiXDjSTg=; b=CYUCVDtAJqPGl3jkaC25lF5EA2oD0gXiIx5hbxq84jJWolDQ5ltHJiS8p8lwy1XDsi JuE5mQ/IieGi7q4UE2n6DW5Jj4f1jwW6YNgRMPlozfIvIqE5yiq/Wq3TsPJLao2iGyIm 98tpa/7j9ztbUm6IDXXPbJxNEhX35xNnWkqnDgkm5BoVzKvzbBs7KRwoTJaa7XEmtDce c2hwhfNZz2cK/Fj0+spLWTO82x7CCV7bK9U+FbuKlFsQqFpWETw2hgtAItEW+s4geAmH s7tw98DYvrjvNigjZjq8Mt9WczFFG1X8gbYNa5hIr8gIYWdXm4jTNBdldKwSPDKNg0JN Tedg== X-Gm-Message-State: ALoCoQktOvE1xwS0GSDjOtic5avhMMLKXKo9F07+FF0b7nYBGr1BUShEdH2PsiFM0SCgTfa9B2fk X-Received: by 10.180.100.71 with SMTP id ew7mr1858437wib.0.1441414654387; Fri, 04 Sep 2015 17:57:34 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.37.228 with SMTP id b4ls112940lak.28.gmail; Fri, 04 Sep 2015 17:57:34 -0700 (PDT) X-Received: by 10.112.133.100 with SMTP id pb4mr6227462lbb.5.1441414654220; Fri, 04 Sep 2015 17:57:34 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com. [209.85.215.47]) by mx.google.com with ESMTPS id z12si3772035lby.131.2015.09.04.17.57.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Sep 2015 17:57:34 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.47 as permitted sender) client-ip=209.85.215.47; Received: by laeb10 with SMTP id b10so23340469lae.1 for ; Fri, 04 Sep 2015 17:57:34 -0700 (PDT) X-Received: by 10.152.26.163 with SMTP id m3mr6247041lag.86.1441414653981; Fri, 04 Sep 2015 17:57:33 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.164.42 with SMTP id yn10csp232514lbb; Fri, 4 Sep 2015 17:57:32 -0700 (PDT) X-Received: by 10.107.46.12 with SMTP id i12mr12061371ioo.17.1441414652504; Fri, 04 Sep 2015 17:57:32 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id rd1si6970377pdb.167.2015.09.04.17.57.31; Fri, 04 Sep 2015 17:57:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964985AbbIEA53 (ORCPT + 1 other); Fri, 4 Sep 2015 20:57:29 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:38389 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934944AbbIEA51 (ORCPT ); Fri, 4 Sep 2015 20:57:27 -0400 Received: by igbut12 with SMTP id ut12so25743854igb.1 for ; Fri, 04 Sep 2015 17:57:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.47.52 with SMTP id a20mr12588384ign.10.1441414647154; Fri, 04 Sep 2015 17:57:27 -0700 (PDT) Received: by 10.50.102.5 with HTTP; Fri, 4 Sep 2015 17:57:26 -0700 (PDT) In-Reply-To: <20150903112647.GD29274@localhost> References: <20150903112647.GD29274@localhost> Date: Fri, 4 Sep 2015 17:57:26 -0700 Message-ID: Subject: Re: Regression: can't apply frequency offsets above 1000ppm. From: John Stultz To: Miroslav Lichvar Cc: =?UTF-8?Q?Nuno_Gon=C3=A7alves?= , Thomas Gleixner , LKML , =?UTF-8?B?R8O8bnRlciBLw7ZsbG5lcg==?= , stable Sender: stable-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: stable@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: john.stultz@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.47 as permitted sender) smtp.mailfrom=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On Thu, Sep 3, 2015 at 4:26 AM, Miroslav Lichvar wrote: > On Wed, Sep 02, 2015 at 04:16:00PM -0700, John Stultz wrote: >> On Tue, Sep 1, 2015 at 6:14 PM, Nuno Gonçalves wrote: >> > And just installing chrony from the feeds. With any kernel from 3.17 >> > you'll have wrong estimates at chronyc sourcestats. >> >> Wrong estimates? Could you be more specific about what the failure >> you're seeing is here? The >> >> I installed the image above, which comes with a 4.1.6 kernel, and >> chrony seems to have gotten my BBB into ~1ms sync w/ servers over the >> internet fairly quickly (at least according to chronyc tracking). > > To see the bug with chronyd the initial offset shouldn't be very close > to zero, so it's forced to correct the offset by adjusting the > frequency in a larger step. > > I'm attaching a simple C program that prints the frequency offset > as measured between the REALTIME and MONOTONIC_RAW clocks when the > adjtimex tick is set to 9000. It should show values close to -100000 > ppm and I suspect on the BBB it will be much smaller. So I spent some time on this late last night and this afternoon. It was a little odd because things don't seem totally broken, but something isn't quite right. Digging around it seems the iterative logrithmic approximation done in timekeeping_freqadjust() wasn't working right. Instead of making smaller order alternating positive and negative adjustments, it was doing strange growing adjustments for the same value that wern't large enough to actually correct things very quickly. This made it much slower to adapt to specified frequency values. The odd bit, is it seems to come down to: tick_error = abs(tick_error); Haven't chased down why yet, but apparently abs() isn't doing what one would think when passed a s64 value. Anyway, the attached patch seems to improve things for me. If you can confirm it resolves things for you I'll run it through some additional testing after the (long holiday) weekend is over and try to get the fix pushed out. Thanks again for the issue report! -john Tested-by: Nuno Goncalves diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index bca3667..81dc975 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -1586,7 +1586,7 @@ static __always_inline void timekeeping_freqadjust(struct timekeeper *tk, s64 interval = tk->cycle_interval; s64 xinterval = tk->xtime_interval; s64 tick_error; - bool negative; + bool negative = 0; u32 adj; /* Remove any current error adj from freq calculation */ @@ -1604,10 +1604,12 @@ static __always_inline void timekeeping_freqadjust(struct timekeeper *tk, return; /* preserve the direction of correction */ - negative = (tick_error < 0); + if (tick_error < 0) { + tick_error = -tick_error; + negative = 1; + } /* Sort out the magnitude of the correction */ - tick_error = abs(tick_error); for (adj = 0; tick_error > interval; adj++) tick_error >>= 1;