From owner-freebsd-arm@freebsd.org Mon May 3 23:18:49 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A6D6B63FE78 for ; Mon, 3 May 2021 23:18:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FYzS84F2rz3qD9 for ; Mon, 3 May 2021 23:18:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1620083926; bh=CqOEE3kanXHZyfdIm5VdTzlLBdMCw/Q2LTyGKhx/Kbm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HiEWUGXxu7fDHFakoSg97oFaW4c7G3EFeMNNEvCq0S/1TSEdWIb4yz9Y2YycuuhXO3hy4HjS1s7Z0Sxr+gehGVksqDWI6z62xPtAQ0QyoV7pbfM7LP+M2M+CC/7RnLFwDklybiewEq1gCe5LxHYPJbZC1PeaPt8OrvQX2owa8XIePmeSf0rljFMO69kHIiRdQDyuo9VNCM7pe9MXBVblOkG7KRlvF3fLAucHhnJRguKDhsFqyq2nJ5weVIuI4L6lA5ELwkd9oeE6TYETonw8xYVC7wSbCN/mllSPh3p6yS1T4j/yF8z2WQHD1TyWUdY9dHDqhtleBVoAaQBZ2HumsQ== X-YMail-OSG: tmGs5UQVM1n5kL6MTehyteDRnDA0Xtoqur1shdogs_wOKIGbswQiLKkCCqXLi9E BomuNPFEb2RrolYwO8D7Kw79k8nB0SHeXiSVPhX1emhpSCNsR9BqA3WJVX31cPXLtv5U5Gl.FIcF K3EXvnMffuyEXKAx4xs7dYIg9rO4KgBBOKpPJaJfhx6KMxcPV2JttjTqyoanSuPy72_ZctMij2s3 HA3yaNDlajVCV1Wo9r.yvsunZgknKiYfexLEJOiY9fXuvuho6dNGd9bhgpychVi4eX9mbeHqgvK3 gfvbSjMVfsmNorA_RA78jgFJx8oPm7LDWJfR3NUzkfjcD7eHWWgI8IMjJuEjuH44TofFJCMafJWz Ggnd5dKlqMq5loX.RYkvBwjTVf8CbhiwvQKI_b7uYl6jUu9aEKmGjVFOvxJ0ZMU5zlsfnke1m2bc RpuX1_47MpwE.errc1.e6gZrWNnm_ClPATTq72La.A7qWMq5ZhysK6hoocdunb08AUaYewHCJ86v MSAfjleCb0OL9tmLlFcbr9dr9KyS0R6R4L39kh4X8lgvjqNl.qtNQ8M7rc_QyTiJ5ZcCpCk7YQmi VJg7MPS8UXDZOig.PoCgfTFpp25.FPNfZifX9RP8vIPny_P65_NPYfUnP__yai8dLbWrhP6VWR_g 8ElrQFntduzs0cM7EU2GlAzZIT4NCvjrQ_C0KOjzRXAZK4hMVe8yONp_N34eBIpiCLrLEzAtLn_1 SvcBWA1JWB9h9bLra3p_3U3x2f7pBr5SsTx62nLg8RnGBUQE9CW4OgkmwjBccrfbaWa2J1eLQEiE 1UI__PueH3Y7yWvqAJTFzTrL5jxKJoqzB4AYQfnL3EvHpAy5XcWOsEGJnHVwX2nflIw2f2U.MjNl 6nGCEVDcPfvkTG0MWvoOvEoYIBlWyC4V7u3ItV5iIEXKLtqV2lBfhMJ2s.FitFsMz_zMscWdLBsA vjfdpXlXBCgKQgfPAHqJPcD2bU1o9FIUcxY2ptc9PpbNVHTKWIOZtE_NiPndFmIoLhg4WhyU6u1t .fZYfkg50BkHVs4aOIovwtqJLOUmSQfdwRg7jyNa38h_EnrCKGRfuuhoDVu.6QRKkG_0SMANhM9L GJH9Em5MPyqfnKbDLxL6TnEdQNYWIyZ_GwdXO.8y384keoDEivHIOhTZPzDCV8dg2RHiOxC6wjB4 PUToXgUTTLMK9VZiG7ckciFrGi.hNZuyJy5pJmdm7jjju.R_W5uuy1eEJyhcDdRnea48SjuuT_j_ T6rlkde4yA7ksKOABqeVlcgrS3nd_t34hYXpVjD2cCHTB5oAsO.K2E2k5q6wspiCgagpszViuxeC yBD64VVdIzwpXGUqUXGTGK4znDT.JhC2UH0Z6k6aKx2eDd1De_cgNkMIlVrjYUzvmMVEJEHMpXTu mh01xB_Luza3p4gDmrgs2_YKx60PJC6DduswZOq4BJzJIc_lXgkc4H8gJumQURWN7LzZJHi7vCge OSqEZFXqtSEvAnczw..5dAJDLzbYeaDrb5B75.Mg9TmNlttLs98VQFani8cHXLqt_eVBIwwbXB1K eSwp0yWAXnU7yaPwdlgCR8LuoAuDmQiia_AKBBzvLfMzG76PRdq9UG0ZsuorNThm0SWhspkQN5Ut qjL72LmVBRvFW4s6s16SnLH2GdGAsJkAxLDz9tGv6OuQn8Wt8305qXxgMolWqQqJejGuk1uKHGTG bZ9gwL1TCX1hk4t1wDM3cVY_JjNmz5CyDriWNdRtYy7ldILFHhbxLWMsChH1jTQXTrnhe.CbSqQi X5ll8u1lG9iccdGPmL1sTUnM2rkx9oJVzq_ue0bzIiOULWBif.Ko3aCON3rnEvjvdU.7pHURb.Mu CnkIHFlvEqui8UqlE3fiU0Y5MmCM9yTNyuwM4n6ZM6Aztknbq4ClJEJqPztdo8BqNZns8F9lNFke YvfoGGHdyy6w4LXjZUwypLo3WNJZR7cMPFr5q57lbxqyjTeHqqb_Rxfyvi7mqIKnrBCU.Oo7sB7. Zgns3v9JWV0BoB7tF7CJU92QI6z.tw78_Z2NhFzuvP62sriwSu5sTUV5hAYNyvilxgQgYIgg0oqL NVC38advK3ULocCj5vIBeUOA0PZOix5zTsDbcUrKd.eCdtoRYfTuN7oeQ.M_krwcFPJx4TQThI4A dCOp6wmScTH0fj_68UpJQ_xJRaE8s0uQNiF5Hpmiz0q1zKKhGN8FcY7P8_45LBqGOgz9mDkJL3yO Z0bywE0y2nZuFzKSjFonFw91Ge2lyDQ6RGCUSglG9o3DvPDA5IpIXH5BuvAiyEh5wVJLCcehTnf5 W.HNUb1m1QALNplEw9loqTqLEPZB2SGBk752kl8VIA4EN3EAKaQ4XRTkSrPB4tTgJkqVOXmr7i78 WuUZ2ZU6YFQ_WHLUN7bzfeRvuID5uAOsV8_LtG9S0.aMHR3ffFMJldZmgzx0ByWDxpYkZmeW_2ws uV_i8mn43eiFlUYGCA.Yptu1GtIXALh.Lurwo0SYCW3Z.sRJyD1sQl3deGFxN9rIdHrxUetfyEsG VOi19UgY3joPA X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 3 May 2021 23:18:46 +0000 Received: by kubenode557.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 70700c81fe8d54e11fed506ea4a6dd0c; Mon, 03 May 2021 23:18:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: Timezone problems on -current From: Mark Millard In-Reply-To: <20210503223811.GC37236@www.zefox.net> Date: Mon, 3 May 2021 16:18:42 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20210503153442.GB37236@www.zefox.net> <3E0512C0-7667-44C4-B64B-501783C5B210@yahoo.com> <20210503223811.GC37236@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4FYzS84F2rz3qD9 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 23:18:49 -0000 On 2021-May-3, at 15:38, bob prohaska wrote: > On Mon, May 03, 2021 at 11:24:02AM -0700, Mark Millard wrote: >> >> >> On 2021-May-3, at 08:34, bob prohaska wrote: >> >>> It seems that the timezone gets screwed up each time the OS is >>> upgraded on a Pi4 via sources on -current. ntpdate is working, but the >>> machine reports a local time of >>> bob@nemesis:~ % date >>> Mon May 3 15:27:04 PDT 2021 >>> while a Pi2 reports >>> fbsd@www:~ % date >>> Mon May 3 08:28:35 PDT 2021 >>> >>> The timezone is PDT in both cases, but the time shown looks like >>> UTC for the Pi4 but PDT for the Pi2. >> >> Note: I assume that neither RPi* has a RTC, not that >> it makes much of a difference here. >> > Correct, no RTC on any of them. > >> I expect that one RPi* has a file: >> >> # ls -Tld /etc/wall_cmos_clock >> -r--r--r-- 1 root wheel 0 Aug 8 01:49:01 2017 /etc/wall_cmos_clock >> >> and the other does not. > > All RPi*s in my collection report having /etc/wall_cmos_clock, > including the one displaying the wrong time. So much for my expectations. > Some are Pi2, running > armv7 12.2-stable, two are Pi3 running 14-current and 13.0-stable. > The only one showing wrong time is the Pi4 running 14-current. Do all the RPi*'s agree for there output for: # sysctl machdep.adjkerntz machdep.adjkerntz: 0 ? (My example context; yours may vary. But to get uniform handling, you would want all yours to agree.) Do all the RPi*'s agree for their output of: # strings /etc/localtime | tail -1 PST8PDT,M3.2.0,M11.1.0 (My example context; yours may vary. But to get uniform handling, you would want all yours to agree.) I'll note that: # strings /etc/localtime | head -1 TZif2 indicates the format-version of the file from what I can tell, allowing some cross checking for things being as expected. "man adjkerntz" has information on the subject. > When the Pi4 finishes building www/chromium I'll start experimenting > to identify just what I did to get the clock wrong. The obvious test > would be to correct the time with tzsetup and then update world and > kernel, reboot and see if time is again wrong. If there are other, > better things to try please indicate. I've never seen timekeeping > problems and know nothing of how it's done. I'm not so sure that this large-change would well isolate the problem --or be likely to change anything. > This begs a question: If I simply re-run installworld, without updating, > will it overwrite the existing world again without rebuilding everything? If you avoid buildworld and just installworld, sure. (buildworld after installworld will rebuild various things because of changes installworld makes, based on what META_MODE tests for.) But I'm not sure why you would do this. I'll note that there are other targets for installing some types of files, but they tend to destroy local tailoring and so are normally only for starting over. Otherwise etcupdate or the like deals with file adjustments in a way less likely to replace your localizations. > That would speed up the experiment considerably. > >> >> There can be an issue of time going backwards, depending on >> the delete vs. add action for /etc/wall_cmos_clock . >> > > I've long wondered about messing with time settings while the > machine is doing something important, like running make. Is that > something to avoid? Yep: avoid time changes in the middle of other things that are based on comparing timestamps. make, in part, uses timestamp comparisons. If date output ends up before file system dates, waiting for the correct time order can be appropriate. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)