From nobody Fri Feb 24 21:52:48 2023 X-Original-To: freebsd-arm@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 4PNkCf1Mk0z3v05b for ; Fri, 24 Feb 2023 21:53:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 4PNkCf06nRz4207 for ; Fri, 24 Feb 2023 21:53:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677275579; bh=c8rpSQm39LKxmY7wLZwap7TztJClQlXvdFlQsGXHPe8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AVs/Z08lq7Z+1Ig9rsAIWRdSbDHE8GRtcY6eISEcQ9k6gibcfiqipXiXzl0wlW69EgmM+tRiq72vL4FyEejz7RTTN4N0sVV5bgO0Iwnh27Ap0hULh3YBOc3ERCf76dAmEdz4ynpUoNtMbtO3BZD/+iXwHj5IebZc3zbCjWY8iL49oYoc0ShPhSKFjBLJhgdD2wKMzeZLrc8Wkz3FN1s3C8d9R+uXthAzSwdX+j64IDb3i4bpVoyLdN9f2Q89dMgpsrZjDBOWUy/3dw332p++Ye4yaHomoEJ9qC82xS2ZsdF4quzgFbEh7Hhsa4rUeQOj0tENRQGN95sdptgCkwl4tA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677275579; bh=9DFmdAMg+4SwQb2EcHxH9he09GsE7DfmawB1mNMwyfD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=l27p5sw+prnLHVsqWN7/W1r+mAOeher/pb4Fze3FVsBuS9J/hGRNGHy+yEKcOME7ncVrmakUPHlaYSjkv5gTAyRa/7zCB+b3BoBJh/EIWemspFOID/I/UwjV1JAim4Vm8RsqfeltIppb5vb5URHEwTZSOK0pWEv+/Sh4IDEvIh5H4cb2Aktl0HyKE4Kl91w2xatxPRijT3rkOqCRfhVEDdTQClBfbrRfTFDLPE5juHHrBzC1Rxf5Y9HfI1IbnKNejp3waLYp8Qq/xXkV9abu3pw3v5dzxgwKIaF66josjVBDXhEQmvhmb3VVBgvtvByTT86LuCCQEMgKlFfY5v8X2w== X-YMail-OSG: i2YYsXoVM1ltLSDr5p00_k23L6klgBQ1W4UYPzQ7Fh9N1oFChYOoC40D3ODbVmd H02FanCFNM6LFyCSCoeA_Bhvgz5t9pkwFfTa6h.hjX6t9nws4dBUuQwnjO0hpDiGm_ZgZFCFRj36 BbBBP_2TedUzZhAEoByTHRqH.13yg86ES.G8m27c7gMNqnV5kh0nYev2uT1OyezUp94Kljnhegyy sO5zeuFGBKpeT_s_lH86quuJ3ESj7v5_TJtQ0P7.Jkjugy_AH2yayr0uqLs6nfWb1C8z9pcl6sS_ UnjYvIvXDUK56UjMyKj46MZw.GCHtVHg60Qr9myc1LicSbIQtO_QrBBEFYKCkYdb0JY8Yz4ogCmg 3j0MLlUrApu_vC0Q2Or6.qt2d3ZhWtagdri2BnDRcRRpyA7lHRdkD2k1W.tbT_f8Mjo_dRJBFlzq RpFHnS.AxfeB_1xn8EUZzZpK47hDnYGbog8GREHNMmEPELZFMTqoCyg8N6H8ZcG5au0OgG.Qk8cP 4au7Sj3Cq5XpkKFwwa7_JpS2vbmeJU5Qs9Uo9axwGzSpRibR8l1lmyeu5lI9QW_NraB8qqaD9HlV amfUfDWaDAWm80va_6t7.UIw1BWUeAhtY0SGNLA25VvPEzByBzKgPu.Ow.7g31wu97wdNo7m2J22 33.gO6gpuq6ysJyq548DnO1FfdYBlM3pwPE0Noad4qLH2SNuSQsuniGMKA3G6JwC8pA877StAXVG P6obuWus3lEVdnI8FowvXpkOB4dk7ktp9ZhEyKGRcEWlpICudccc2tPoGOXjPfJDgZAqKvnCqTNR AQFx4bbbS6N1IIYLQlxnq6JvZoGUVV3kZquxpgynQcTSjTg97ry_UoRkHqs0d84Ab6pRzylaW5gi 2xBqrgDv9IBIBjnIiZBR0Rz5lfhj4yaXnHOwZYk1HPaC0mAQTObreVZ9bl9VRu8d27raRUxqw9FB 6ty2j7Oix09c2BngFr.Bbnnvyr0KtEQdQTzxN3Xp7DcKuLyKmoWDTZtjvMeML.FtiH16MlqStiWp Yzwi9fFCq45ERxBFve7VB_.IJslEfiVfAUZ.mCWYrvkBlWXnUq0MXaOrfV_HGmBhZV6veHlrC244 QiVbdylXnpYgAGGIq7dI0UFknhl4rTzcbxiS5d1JVgcamRIj7yT8XBOo_lmhMcWKKLOE_ANrCiQy 3Yaya_0Y_47A0w2lGRfNHrdLmOOplCHrlLZng2nwKjZ6wEPRTKwTECH5K.bVj7Y2Hvp2krHdWblE gSvZHcS8Rw_Zcj3qgZ3eLawhIVxzZHZ5sl8XCA2kfPukjqLYRcQ1z4PSneVvSPmvMSkES0BpyfBV E_Xd7JvoTPGYxkDfzhaf_wOzWvD8gtLXRosv0AQAsj94U08GhLQ7uyS1ZU2caBcpSLi7abSlmSeR Dbw4beEo1VCZ66W8O5FZIPV2KAKh_5KsJ4.qWz5.46j2Q7NKt_mLmL5oDx1U5pW3jRtxlhvUyS3f IFNOxjhZWqRajxVSxW59BVDtt57iJgDJDebTJBR4ZaiH07GqrekScDAKF0UbOpaE9uZyG8DM5wCo Q5x.Vn6ioqXVmz9JLgCoIv4yVyEdszwz03QuUEpJkMv84.1WfqYXfcxkNNXhKHQz.kkvtGxkZ1bV iM83D0xJ6pVGfqeQyzGbH2wz2ocdvns5.LjCg7EwYqYeQp2zjigyi7KpNuJB1iM_lAO2M3UPuEoG ZwYK4mrefRrH4IK0EwiO68kqpl7mesm2Y2nrjRsK4AauYk2veTYBMd8HJeNzxjjIi7ICbUm49ouj nxDUtNEdScxBAdmXvjbGPl6ZwKQK8rp7ZVEGLXcoZL0uWQmtKbL7slz8nlhweSvnxGrKcGgg1dYN Ap06ruHydLDUxLGISSEJG.NLMQZhRuebO4Lpm.JrOasi.KGq80xv3vJ.KtHehRdSp2ohmmB3dPlC 3R0ocNSPLW1uXfdF1XmMzsSDVILVst9CpTfvqvRa8fJal9uSagZxCSvwa1XW5PRWm24Tb.aB2B5u zr_D5MKNIRQ9zdENSmMiJqkgrO0qCuX8Oh8AKvMT2ppDfi4BFdqHWR1OEXZfXK3FqOalg17BYXhg PXVrlWB8VbOHCF0jeWEmtkZuYE80EAHg8KFVgPBzlCGAulXuc9v_lxbTqQPG9fnO9EIpM6Xe54Fh n408Z42vrA9m36V6wQk7TL8O1ARcFV6uAvAqY0VlS3.DoA5Qq151ij51ExRV78jqmzyN4wWlSApd nLTw.mYPJzA6ji4zA02zwYR3YPkxxoFyBOWCM3GcohNpTxhRWG72H_zX4URzERKFmjsQxcpFflze s X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Feb 2023 21:52:59 +0000 Received: by hermes--production-gq1-655ddccc9-nql2v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7c31e287324c0c661d251f2dfc915b40; Fri, 24 Feb 2023 21:52:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot From: Mark Millard In-Reply-To: <20230224210502.GA8127@www.zefox.net> Date: Fri, 24 Feb 2023 13:52:48 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230224210502.GA8127@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PNkCf06nRz4207 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 24, 2023, at 13:05, bob prohaska wrote: > After installing=20 > = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img > on a Pi3 and setting up the hard disk to use separate swap and /usr = partitions > an oddity came to light regarding dates. >=20 > The image file was written to disk the night of the 23rd, from a Pi3 = with > a correctly-set time and date. It was left idle overnight, configured = the > morning of the 24th and booted without issue. It then cloned -current = into > /usr/src, at which point the time was noticed to be wrong, apparently = fast. >=20 > It turned out ntpdate wasn't running, so it was started and then = tzsetup > run. After a reboot the time reported correctly.=20 >=20 > However, make buildworld in /usr/src triggers an exhortation to "check > your time" and refuses run further.=20 >=20 > running date on the system reports > Fri Feb 24 12:49:41 PST 2023 > but ls -l /usr/src reports time around=20 > Feb 24 19:10 > an obvious inconsistency. >=20 > Presumably just waiting until the system clock catches > up with the /usr/src timestamps will fix the error. Is > there a better method? >=20 > Still, the date and time handling don't seem quite right.=20 > In at least one earlier instance it appeared that tzsetup=20 > altered the reported timeszone without shifting the time > stamp by the UTC/PDT offset. I always thought timestamps > were internally in UTC+timezone, displayed with the right > offset. It looks to a casual observer like something else > is going on.=20 >=20 > An earlier fiasco (on this same Pi3) included wildly wrong > timestamps in a filesystem. The Pi3 has no hardware clock, > how does it set time when booted without a reference? There are 2 files involved: /etc/localtime Current zoneinfo file, see tzsetup(8) and = zic(8). /etc/wall_cmos_clock Empty file. Its presence indicates that the machine's CMOS clock is set to local time, = while its absence indicates a UTC CMOS clock. An oddity here is that there is no existing CMOS clock but the /etc/wall_cmos_clock status still has consequences, as I remember. Various related man pages are: adjkerntz(8) tzseteup(8) zic(8) =46rom an RPi4B: # ls -Tld /etc/wall_cmos_clock ls: /etc/wall_cmos_clock: No such file or directory # sysctl machdep.wall_cmos_clock machdep.wall_cmos_clock: 0 (So: As if a CMOS clock was using UTC time.) # strings /etc/localtime | tail -1 PST8PDT,M3.2.0,M11.1.0 # sysctl machdep.adjkerntz machdep.adjkerntz: 0 # date Fri Feb 24 13:42:52 PST 2023 (Matching the local time.) So, as configured, /etc/localtime is used to specify covert kernel UTC to local time as needed: no addition non-zero offsets. As I remember, things can be odd with file systems from Windows variants and the time stamps interpretation. Keeping such matching vs. not can get into the choice of if /etc/wall_cmos_clock is to exist or not. It can be a seprate issue if time tracking is off rate or some such. =3D=3D=3D Mark Millard marklmi at yahoo.com