Date: Mon, 19 Aug 2019 08:47:46 -0600 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: "O'Connor, Daniel" <darius@dons.net.au>, "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: <f4963626659c115be8306a079be798afd8f0b38e.camel@freebsd.org> In-Reply-To: <CANCZdfoVJ2ryUr%2B1uh9iCHKLWZO3MONAB9xv3MpWpzYqhycEyw@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2019-08-19 at 08:32 -0600, Warner Losh wrote:
> On Mon, Aug 19, 2019 at 8:26 AM Ian Lepore <ian@freebsd.org> wrote:
>
> > On Mon, 2019-08-19 at 17:09 +0930, O'Connor, Daniel wrote:
> > > > On 12 Aug 2019, at 09:09, O'Connor, Daniel <darius@dons.net.au>
> > > > wrote:
> > > > > always get lost on single-core processors which are in cpu_idle()
> > > > > at
> > > > > the time the hardclock interrupt happens. (But that's fixable by
> > > > > just
> > > > > increasing the number of timehands, I think at least 4 are
> > > > > required.)
> > > >
> > > > OK, how do I increase the number of clock hands?
> > >
> > > I am going to try this diff but buildkernel is going to take a
> > > while...
> > >
> > > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c
> > > index 2656fb4d2..00440b6a2 100644
> > > --- a/sys/kern/kern_tc.c
> > > +++ b/sys/kern/kern_tc.c
> > > @@ -83,8 +83,48 @@ struct timehands {
> > > struct timehands *th_next;
> > > };
> > >
> > > -static struct timehands th0;
> > > +static struct timehands th2;
> > > static struct timehands th1 = {
> > > + .th_next = &th2
> > > +};
> > > +
> > > +static struct timehands th3;
> > > +static struct timehands th2 = {
> > > + .th_next = &th3
> > > +};
> > > +
> > > +static struct timehands th4;
> > > +static struct timehands th3 = {
> > > + .th_next = &th4
> > > +};
> > > +
> > > +static struct timehands th5;
> > > +static struct timehands th4 = {
> > > + .th_next = &th5
> > > +};
> > > +
> > > +static struct timehands th6;
> > > +static struct timehands th5 = {
> > > + .th_next = &th6
> > > +};
> > > +
> > > +static struct timehands th7;
> > > +static struct timehands th6 = {
> > > + .th_next = &th7
> > > +};
> > > +
> > > +static struct timehands th8;
> > > +static struct timehands th7 = {
> > > + .th_next = &th8
> > > +};
> > > +
> > > +static struct timehands th9;
> > > +static struct timehands th8 = {
> > > + .th_next = &th9
> > > +};
> > > +
> > > +static struct timehands th0;
> > > +static struct timehands th9 = {
> > > .th_next = &th0
> > > };
> > > static struct timehands th0 = {
> > >
> >
> > Oh, I'm sorry, I forgot to respond about this. Yeah, that patch would
> > do it. I think a minimum of 4 sets of timehands are needed for pps
> > capture on a single-core system with a latching timecounter like
> > dmtpps.
> >
>
> Do we have a good (or even a bad) writeup of how to know that 4 is good, or
> when 5 or 6 might be needed?
>
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.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f4963626659c115be8306a079be798afd8f0b38e.camel>