From nobody Sun Apr 23 12:42:54 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q47GV5y9lz45NZr for ; Sun, 23 Apr 2023 12:43:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q47GS5HHKz4WDf for ; Sun, 23 Apr 2023 12:43:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=A6Q+AwcI; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682253790; bh=6AqhNPoQoutZG7yu0ofNDUcs/vjdTvWJDBOD0JhejVU=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=A6Q+AwcI6u9Y49DagJLROwDEnAopE++mIegPFe2CZUrmeomZbjaKsGBdnXz8o00Nr93tmayaaA9dM0VzD7Y9yMlmzQB5iyiqfg6mys09hNv/NpH3hmq7+adcU01y+sH1kfSOQ7Q/6FClQ3LTlx3WpDFHDk4dIMREXlP0VhjacTeN/jeqrVlkqWywN8gnYGE1NmYzJqncWcXpcR+LKX1QOE9t4I+7D2eE04PwSwHiP4/eF10PqWgGZG81xyVl7w5qHuPVl0m3NlQAWdmNdqa2/keMyDFH7+BdDqZU3cvs9qc96EExAdWbAI78/wXTynDLSt6zAv8V86Y7LbDOnWnxNg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682253790; bh=w4Wn2eI00kVYRSZzQ3BYotoSdnDNIPHtTABHJFADykl=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=JpJG3AKewmU4H35pZ0W0ndlp9FnL5ylm3DjfcfYkfQlJycHaso/IvSqGliMIiwaZjsrfmPsVnAYfg5MjWUO/iOmRWq/2AtefU0uXCWNeT+YMgrz+EOZkFdU2PPGeuZ1Adt7fxkEV1MbJ/+/HZbucoyvvdV47/Sm430n/ovAMR95hEmooiKnlB+zenPKBw9M61AgUtn78UcqOmRbKydw2QcdvIxQYkS/sBxJxC85E7rnZmVgOCAu6vp4OZo92N9K6VSQQvtKDWG8BL+PLUPhgK0SKywU+yijKmQENvfiQeA0vI3FWFUFcHExqWqico6JM/vsbxP4Il3ROPNcnA+tD7g== X-YMail-OSG: h2pw5MMVM1k67PjtEu.pcR74vueq5iwmU0slZqAqImgxJjxUdC0hWrMqkKqGqw4 VqNECUTEUDH5M5Qwre44QzFlHN4GPxVljIh6sh75T3iFiAyayiAuusyKaNdQKXcKqs0FSbuQjl9j 0jhSkfXrYzrPLnM_LBIMR5Sv0_5wn9n8_Fnf2UjB7GtCm4ysQ_ONFNkTO4LFOiwanJ3WGnhTH4xE Wo6hi2VanCbAz3EgtaKYOS_PDsAm4Nyoq6VxBqWmpVNs2rvqqvcBHTin0NtgZpGmeusevx2B3bLy mDk35TyD0hl0037U5Z3l80q5K4rHTWF22zbz2SrTLD8BqWqVJqzXWx4x2ex3bkZf._tcatsPcOH6 NeHaKCXBZMIprbZ4wkBqJkcPF3B4b3vsGc.iIU36jFeGph_K1ig89yO5Rl2g5VPri2nIBxd5ahPy O.aiIJq_sttbcrU0y.niyG8s4xJ.nfT9iF_lwsHyBA2ectp1DNcOOkz0bSEnrv490mEjtvcS7fxt .9hDUSHjHQRdcrcJUBOjKmDMqspzRibvvr0LgS3g0Vf3H8YySHh0z1KoKB0k1ZeKCfMXvbXzKrlf t3G.apr4aoDkpyfD3f0VuIFhHPo0i9OaXbYKSUGvnMs5C7Fd1aodrbG7VudDJ6Of4iG9tx.Q166p byVR4lL92ynMAQxx1buGpl2dOIg9uGXUOPVeoIzKDmUlexh.9_VbB6.4hYTLk7kR1L6fg8mSIdL1 3hnWEVKRg5VDjatR_wsrAvK..obGcDLNX.VUME4LZzHPyDg_d.tz2R1N82NR9KtvMTTEZyTjSgfC XIl.JRXj9cVj9syUjnQjc7GqA2hwTi6zmqAS7tw0bmGUpaB_lK9pRhK9DFdQ_FiyvNCXCkLANMrP CePokNUJdJc6MmYhLqtKmz.ROGVHkSRdkZRNPMlQiOTV.v02CxR90p3va3Ffp4LpIOpM0YNMcnN_ 4E.xro3iE8acqloz733nwpt9pLhyFiJgy_6HTygDR758Cph2FR6GGJ9yODP9rSTBlBhYKz0EDxr1 zGHnTzMqdh3_2r1ky0IweTf94kKYR854RkuXht5Mp5Zqn6W0VSU38QZhu1jWugXF15aGpEqTlP9b KQYoW8H0CaDxd8qD_Myh7qEcbipTL5tasrqO0X1EkNnioBhN6UHWqE0pJpkpLzIaPgr7UeAL.HsK Cr_oWjPwstj_M.uUVfBQCaHe7B3.ReAmFNxaCbm3QR0F_v3PYs_3jvWx8gbgw_io2HEAFkjLHU.d HG7GLvkVIlC0ftFbmcjiWog4tp0QkinEiMDfYNZqr46OklEVH1D8PGu0fHPu4NAL8mCBPh3o_1vI qiGnVnJlhWXpxYnSsDu_buhVXC0yQ9IVD_8u5X6XcXVTSphK0M90gu_3jgR3nsqwz6HGEog_EElM dh_PnPipVLLSBsAkb03S0kYNmhnZuMNALP6g0hIhORbc2ZD.wXxzcL2TCTKRt3ip9QRWD0XHHq8V E4fwEBOpL0sNEJfnw3GMe.0DxDGUk5rOiJ55.4nwCdlkU4XEuEdlpy65Kg_tQbYzZ5Y7uSUXoleY 6t0gObXFZmiu273jln1VgCZ0cj5xSsWsSUNnsz8xIqHUMvrU5zZdIVplhbK4CnYOmn4Cr63ky.8t FJP5OUIH_cSsdefYc9tE2Rm0m6oIidSSEsqzyO.opj8_e4iLD07WWJshghvDU5ghVwV_hU_1.NJW yNDM8NIdcT19YWor3T1Xkyqt6Xc1az51lfNHDdzLBLIxGUznAu2.2ipjADYs0Lr6z4xrji7P1aty 0YZ9HylBlrUqaGNf7ZrQgxxqjcGTMgdPx9TPi0RueRMmDrJDPec1u1CrgFVCI5olCIs_VgWfEvzB 2.xWrizRzxmUrwLz4Ht6pM8X5fd7hBXOSboXHMwsYjzIrvOe0xcd.hKBq7DwPd.SB0eDzyBBpe8I jIBYUItL_b8ik_8j_wgcpD7XGxXTHAXVmAZMJ.g7JHPXndQ_rububNJ3jmSNAOP6QNYFVuBvBLJS 72WC5lUUcVaK3FnDDT16qjwe9KUL5wM_.4ib4K71hfojj4_9j4_Dfudijnrnv6CGb7J4QIWLmRJk bkbTcqXmK4CC4FP1JafixQSTnoSkE7VfcsXXqSwFmdeUTssRrT29RkvIN07z.1qWHJEBxcmFnm6n ne1ECv6ksFSb2fOpvT6L66G8cIY8cac3t87roaMsLyke2LRTmgc8FCXBtMnDIKQbT76HaapB7gSM fWRk32qYw9KiJmS4.nD2s71elssr2zAKV5x2wapf3OouEcsb.wB4plTYhP1ZKBkzElzeMXSoFfEq T X-Sonic-MF: X-Sonic-ID: db8d2018-09cb-477c-9401-2da3d1a621c6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 23 Apr 2023 12:43:10 +0000 Received: by hermes--production-ne1-7dbd98dd99-gdhzk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 47a26aba6789bb49b1c1f5602c88b19c; Sun, 23 Apr 2023 12:43:06 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: ntpd fails on recent -current/arm64 Date: Sun, 23 Apr 2023 05:42:54 -0700 References: To: peter@rulingia.com, Current FreeBSD In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-2.71 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; NEURAL_HAM_SHORT(-0.21)[-0.209]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4Q47GS5HHKz4WDf X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Apr 23, 2023, at 05:29, Mark Millard wrote: > Peter Jeremy write on > Date: Sun, 23 Apr 2023 11:47:01 UTC : >=20 >> Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, >=20 > I see the problem at main-n262371-72ef722b2a34-dirty (aarch64), > in the middle of your range. So in the smaller range is: >=20 > Thu, 20 Apr 2023 > . . . > =E2=80=A2 git: 607bc91d90a3 - main - vmrun.sh: Fix a typo in = usage() Mateusz Piotrowski=20 > =E2=80=A2 Re: git: 373b95976bce - main - netstat: document that PCB = information can't be read from corefiles tuexen_at_freebsd.org > =E2=80=A2 git: de1dde5dfea4 - main - network.subr: adjust regex for = wlans_xxxxx rc.conf entries Bjoern A. Zeeb > =E2=80=A2 Re: git: 8dcf3a82c54c - main - libc: Implement bsort(3) a = bitonic type of sorting algorithm. Brooks Davis=20 > =E2=80=A2 git: 7db7bfe1a7b9 - main - iwlwifi: quieten more compiler = warnings Bjoern A. Zeeb > =E2=80=A2 git: 35f7fa4ac1ae - main - LinuxKPI: 802.11: improve = assertion and tkip code Bjoern A. Zeeb > =E2=80=A2 git: fdb987bebddf - main - inpcb: Split PCB hash tables = Mark Johnston=20 > =E2=80=A2 git: 3e98dcb3d574 - main - inpcb: Move inpcb matching = logic into separate functions Mark Johnston=20 > =E2=80=A2 git: 7b92493ab1d4 - main - inpcb: Avoid inp_cred = dereferences in SMR-protected lookup Mark Johnston=20 > =E2=80=A2 git: 5fd1a67e885e - main - inpcb: Release the inpcb cred = reference before freeing the structure Mark Johnston=20 > =E2=80=A2 git: dd9059b3e9a1 - main - makefs: set cd9660 Rock Ridge = timestamps for . and .. Ed Maste=20 > =E2=80=A2 git: 0df4d8ad7a1b - main - Add jobs.mk to allow for = target-jobs Simon J. Gerraty > =E2=80=A2 git: d1f4c44aa8af - main - x86: Move i386 ppireg.h to x86 = Dmitry Chagin=20 > =E2=80=A2 git: de4da6cd04bf - main - x86: Move i386 timerreg.h to = x86 Dmitry Chagin=20 > =E2=80=A2 git: 8fe4f8f7a75f - main - Fix building host tools for = host Simon J. Gerraty > =E2=80=A2 git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Hans Petter Selasky=20 > =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Jessica Clarke=20 > =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Brooks Davis=20 > =E2=80=A2 git: 1a149d65baed - main - dtrace: get rid of uchar_t = types Mark Johnston=20 > =E2=80=A2 git: 080e56a6c98c - main - dtrace: expose = dtrace_instr_size() to userland and implement it for riscv Mark Johnston=20= > =E2=80=A2 git: 75081b9ed8e6 - main - dtrace: use = dtrace_instr_size() in the riscv dtrace_subr.c Mark Johnston=20 > =E2=80=A2 git: 1fef7abdc76b - main - dtrace: add register bindings = for RISC-V Mark Johnston=20 > =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Hans Petter Selasky=20 > =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Hans Petter Selasky=20 > =E2=80=A2 git: 47e888f8363d - main - Remove a few more references = to riscv64sf. John Baldwin=20 > =E2=80=A2 git: 048606bec11f - main - perfmon(4): Use a C89 function = definition for a SYSINIT. John Baldwin=20 > =E2=80=A2 git: bf043855213c - main - arm: Use C89 function = declaration for db_read_bytes. John Baldwin=20 > =E2=80=A2 Re: git: c1e813d12309 - main - hwpmc: Correct selection = of Intel fixed counters. Alexander Motin=20 > =E2=80=A2 git: 72ef722b2a34 - main - dpaa2: add console support for = FDT based systems Bjoern A. Zeeb > . . . >=20 >> 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). >>=20 >> What I've identified so far: >> * The problem is in the kernel, not userland. >=20 > See below for the truss output oddity of doing > 2 sendto's (no recvfrom) instead of sendto then > recvfrom. =46rom an machine with an older context > that works: >=20 > . . . > socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) > connect(3,{ AF_INET 127.0.0.1:123 },16) =3D 0 (0x0) > sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) > select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 1 (0x1) > recvfrom(3,"\^V\M^A\0\^A\^F\^X\0\0\0\0\0\^X"...,516,0,NULL,0x0) =3D 36 = (0x24) > fstat(1,{ mode=3Dcrw--w---- ,inode=3D138,size=3D0,blksize=3D4096 }) =3D = 0 (0x0) > ioctl(1,TIOCGETA,0x735a71d98c58) =3D 0 (0x0) >=20 >>=20 >> * 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 >=20 > I noticed that "ntpq -c as" end up doing: >=20 > . . . > open("/etc/services",O_RDONLY|O_CLOEXEC,0666) =3D 3 (0x3) > fstat(3,{ mode=3D-rw-r--r-- ,inode=3D14579,size=3D72600,blksize=3D72704 = }) =3D 0 (0x0) > lseek(3,0x0,SEEK_CUR) =3D 0 (0x0) > lseek(3,0x0,SEEK_SET) =3D 0 (0x0) > read(3,"#\n# Network services, Internet "...,72704) =3D 72600 = (0x11b98) > close(3) =3D 0 (0x0) > socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) > connect(3,{ AF_INET 127.0.0.1:123 },16) =3D 0 (0x0) > sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) > select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) > sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) > select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) > localhost: timed out, nothing received > write(2,"localhost: timed out, nothing re"...,39) =3D 39 (0x27) > ***Request timed out > write(2,"***Request timed out\n",21) =3D 21 (0x15) > exit(0x0) process exit, rval =3D 0 I should not have written: > Note the: socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) >=20 > I've no use of PF set up. It just confuses things because the older context also makes that call. It is really what follows (sendto->sendto vs. sendto->recvfrom) that matters from what I can tell. Sorry for the misdirection. > Your "ntpq -p" also gets such: >=20 > socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) > connect(3,{ AF_INET 127.0.0.1:123 },16) =3D 0 (0x0) > sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) > select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) > sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) > select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) > localhost: timed out, nothing received > write(2,"localhost: timed out, nothing re"...,39) =3D 39 (0x27) > ***Request timed out > write(2,"***Request timed out\n",21) =3D 21 (0x15) > exit(0x0) process exit, rval =3D 0 >=20 >=20 >=20 >> * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime >>=20 >> I've looked through the commits and, beyond much of netinet being >> roto-tilled, I can't see anything obvious. >>=20 >> Is anyone else seeing anything similar? >=20 > Yes. I noticed via systems without a RTC that I'd set up > to have ntpd fix the times on. The times stopped being > fixed. >=20 >> Can anyone suggest where >> to look next? >=20 > See the truss output above? (I'm no expert in the area. > I'm just noting the odd sendto sendto sequence without > any recvfrom.) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com