Date: Sun, 23 Apr 2023 07:34:45 -0500 From: Mike Karels <mike@karels.net> To: Peter Jeremy <peter@rulingia.com> Cc: current@freebsd.org Subject: Re: ntpd fails on recent -current/arm64 Message-ID: <33479649-394F-429D-A71B-12B3BC379149@karels.net> In-Reply-To: <ZEUatSH15rzNPqZ6@server.rulingia.com> References: <ZEUatSH15rzNPqZ6@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33479649-394F-429D-A71B-12B3BC379149>