From owner-freebsd-arm@freebsd.org Mon May 3 22:38:12 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 A86F063FB25 for ; Mon, 3 May 2021 22:38:12 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FYyYH2byJz3ntM for ; Mon, 3 May 2021 22:38:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 143McB0q039199 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 3 May 2021 15:38:12 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 143McBKq039198; Mon, 3 May 2021 15:38:11 -0700 (PDT) (envelope-from fbsd) Date: Mon, 3 May 2021 15:38:11 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Timezone problems on -current Message-ID: <20210503223811.GC37236@www.zefox.net> References: <20210503153442.GB37236@www.zefox.net> <3E0512C0-7667-44C4-B64B-501783C5B210@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E0512C0-7667-44C4-B64B-501783C5B210@yahoo.com> X-Rspamd-Queue-Id: 4FYyYH2byJz3ntM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [-1.08 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; MID_RHS_WWW(0.50)[] 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 22:38:12 -0000 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. 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. 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. This begs a question: If I simply re-run installworld, without updating, will it overwrite the existing world again without rebuilding everything? 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? Thanks for writing! bob prohaska