From nobody Fri Feb 24 23:21:09 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 4PNm9N0Gxvz3v49p; Fri, 24 Feb 2023 23:21:12 +0000 (UTC) (envelope-from SRS0=RvKr=6U=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4PNm9M5KCLz4Fft; Fri, 24 Feb 2023 23:21:11 +0000 (UTC) (envelope-from SRS0=RvKr=6U=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Date: Sat, 25 Feb 2023 00:21:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1677280870; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=slq6LhIvHBK8955ssKcR8rkKQwtEeLy4YJK1j6RDNnc=; b=aPjEKoZHReZ8/mFDYRPb2uLRe8wh4Lza4tDIazJbJPoM/BDC69+eLanc0HZJjfPn54EOE3 gf9hNzD+VG07OECsrrahcFkMIREF2BfAKKKFJ2oqDUp6wA9Q2sPZ67vYfSHcWFcgxxIZx5 eLZDNqljrTrjc5YMAvClOhSKzAgfCIaR1bRlz4wK9l2wP+jvSSYWKZFETfuM2XM+TwD97B epv8J1/Sas5YSoA3W++I2SO3vfFiXe+qWxc5RrG+oYgi9+8AnQllcLTAZWno+/KQEGV4ZS iRHIBoUCWUwkdr0PQ4vkhmaeDWHSW489Aj8rdIBoyzopKLWwsqSgmP2MZDEhCw== From: Ronald Klop To: freebsd-arm@freebsd.org, bob prohaska , freebsd-current@freebsd.org Message-ID: <1216867532.11893.1677280869319@localhost> In-Reply-To: <20230224210502.GA8127@www.zefox.net> Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot 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 Content-Type: multipart/alternative; boundary="----=_Part_11892_113718381.1677280869315" X-Mailer: Realworks (645.67) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4PNm9M5KCLz4Fft X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N ------=_Part_11892_113718381.1677280869315 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Van: bob prohaska Datum: 24 februari 2023 22:05 Aan: freebsd-current@freebsd.org CC: freebsd-arm@freebsd.org Onderwerp: Timekeeping problem in /usr/src on new RPI aarch64 snapshot >=20 >=20 > 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 parti= tions > 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 int= o > /usr/src, at which point the time was noticed to be wrong, apparently fas= t. >=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? >=20 > Thanks for reading, >=20 > bob prohaska >=20 >=20 >=20 >=20 >=20 >=20 UFS stores the current timestamp in the superblock of the FS on clean shutd= own/unmount. On boot it reads the time from the timestamp in the superblock= of the root FS. Of coarse this timestamp is behind for the duration that t= he machine was off or rebooting so you need to adjust that using ntp.=20 For ZFS root you can use the fakertc port to do something similar.=20 You can use the command =E2=80=9Ctouch=E2=80=9C to manipulate the time of y= our /usr/src dir.=20 Regards, Ronald ------=_Part_11892_113718381.1677280869315 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Van: bob prohaska &= lt;fbsd@www.zefox.net>
Datum: 24 februari 2023 22:05=
Aan: freebsd-current@freebsd.org
CC: freebsd-arm@freebsd.org
Onderwerp: Timekeeping probl= em in /usr/src on new RPI aarch64 snapshot

After installing
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 partiti= ons
an oddity came to light regarding dates.

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<= br> /usr/src, at which point the time was noticed to be wrong, apparently fast.=

It turned out ntpdate wasn't running, so it was started and then tzsetup run. After a reboot the time reported correctly.

However, make buildworld in /usr/src triggers an exhortation to "check
your time" and refuses run further.

running date on the system reports
Fri Feb 24 12:49:41 PST 2023
but ls -l /usr/src reports time around
Feb 24 19:10
an obvious inconsistency.
 
Presumably just waiting until the system clock catches
up with the /usr/src timestamps will fix the error. Is
there a better method?

Still, the date and time handling don't seem quite right.
In at least one earlier instance it appeared that tzsetup
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.

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?

Thanks for reading,

bob prohaska



UFS stores the current timestamp in the superblock of the = FS on clean shutdown/unmount. On boot it reads the time from the timestamp = in the superblock of the root FS. Of coarse this timestamp is behind for th= e duration that the machine was off or rebooting so you need to adjust that= using ntp. 
For ZFS root you can use the fakertc port to do somet= hing similar. 

You can use the command =E2=80= =9Ctouch=E2=80=9C to manipulate the time of your /usr/src dir. 
Regards,
Ronald

------=_Part_11892_113718381.1677280869315--