Date: Mon, 19 Aug 2019 18:22:44 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-arm@FreeBSD.org" <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> In-Reply-To: <f4963626659c115be8306a079be798afd8f0b38e.camel@freebsd.org> References: <f1d765814f722fb2c99c9870b3cc2607b4eca2d7.camel@freebsd.org> <B9EFA4D4-C1AD-4181-B421-F6BD53434FA5@dons.net.au> <bfd784f6ac9c939dbe6a243336bc3b6eab02d4f5.camel@freebsd.org> <61B1AAF3-40F6-47BC-8F05-7491C13BF288@dons.net.au> <9E142F1A-5E8C-4410-91F5-7C80B3D0A15B@dons.net.au> <fc1ef92211cfc9aeff3b4bd4335d69ceda5e5223.camel@freebsd.org> <CANCZdfoVJ2ryUr%2B1uh9iCHKLWZO3MONAB9xv3MpWpzYqhycEyw@mail.gmail.com> <f4963626659c115be8306a079be798afd8f0b38e.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190819152244.GN71821>