From owner-freebsd-arm@freebsd.org Mon Aug 19 15:23:01 2019 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5BD03C9417 for ; Mon, 19 Aug 2019 15:23:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46ByNj0NWlz3x57; Mon, 19 Aug 2019 15:23:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x7JFMirF077073 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 19 Aug 2019 18:22:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x7JFMirF077073 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x7JFMiMW077072; Mon, 19 Aug 2019 18:22:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 19 Aug 2019 18:22:44 +0300 From: Konstantin Belousov To: Ian Lepore Cc: Warner Losh , "freebsd-arm@FreeBSD.org" Subject: Re: dmtpps driver on beaglebone [was: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.] Message-ID: <20190819152244.GN71821@kib.kiev.ua> References: <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 46ByNj0NWlz3x57 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.937,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 15:23:01 -0000 On Mon, Aug 19, 2019 at 08:47:46AM -0600, Ian Lepore wrote: > I first ran into the problem on a beaglebone a few years ago, not that > long after the number was reduced to two. The number 4 is pretty much > just a vague-ish memory of the debugging I did back then. When you > don't have enough timehands, the symptom is that you lose most of the > pps events (but enough get captured that ntpd will more or less run > properly on the reduced data). > > The busier the system is, the more events get captured succesfully, > because the loss is caused when the pps pulse happens while sleeping in > cpu_idle(); the path that unwinds out of there leads to calling > tc_windup 3 times, iirc, which means the value latched in the > timecounter hardware belongs to a set of timehands whose generation > count is not valid anymore because of all the tc_windup calls, and the > event gets discarded because of the generation mismatch. Is the problem specific to the platform then ? The issue you see might come from tc_ticktock(), but it is strange. All calls to tc_windup() are serialized by spinlock. tc_ticktock(), potentially being called from interrupt context, uses try-lock to avoid spinning while other CPU does the update. But this is impossible on UP machine, because spinlock in top half disables interrupts, which means that event that triggers tc_ticktock() call and which trylock fails should be impossible, until the top half finishes. Having too many timehands is bad because reader get a higher chance to find obsoleted th pointer. With the rework of the generation counts for timehands reader would not use stalled data, but it might have to spin somewhat prolonged time. In fact, it might be worth trying reducing the timehands count from two to one, since then there is no non-current th at all.