Date: Sun, 23 Apr 2023 09:48:02 -0400 From: Mark Johnston <markj@freebsd.org> To: Mike Karels <mike@karels.net> Cc: Peter Jeremy <peter@rulingia.com>, current@freebsd.org Subject: Re: ntpd fails on recent -current/arm64 Message-ID: <ZEU3Erd_RKo8_Tln@nuc> In-Reply-To: <33479649-394F-429D-A71B-12B3BC379149@karels.net> References: <ZEUatSH15rzNPqZ6@server.rulingia.com> <33479649-394F-429D-A71B-12B3BC379149@karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 23, 2023 at 07:34:45AM -0500, Mike Karels wrote: > On 23 Apr 2023, at 6:47, Peter Jeremy wrote: > > > Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, > > some change in the kernel has made ntpd stop working on my arm64 test > > box. (My amd64 test box is a couple of days behind so I'm not sure if > > it's arm-specific). > > > > What I've identified so far: > > * The problem is in the kernel, not userland. > > * The impact seems to be limited to ntpd (in particular, ntpdate works). > > * ntpd appears to be correctly exchanging NTP packets with peers. > > * ntpd is not responding to "ntpq -p" queries > > * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime > > I updated an amd64 system yesterday, and it is broken too. > > > I've looked through the commits and, beyond much of netinet being > > roto-tilled, I can't see anything obvious. > > The netinet changes seem likely to be the culprit. ntpd seems to > be receiving the requests but isn’t responding. Trivial testing > indicates that named is working, so UDP isn’t completely broken. > > > Is anyone else seeing anything similar? Can anyone suggest where > > to look next? > > Mark may have an idea. Finding a simpler example would be helpful, > but I’m not sure what we’re looking for. I can reproduce the problem. A small example would still be useful, so that we can turn it into a regression test case.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZEU3Erd_RKo8_Tln>