Date: Mon, 3 May 2021 15:38:11 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org Subject: Re: Timezone problems on -current Message-ID: <20210503223811.GC37236@www.zefox.net> In-Reply-To: <3E0512C0-7667-44C4-B64B-501783C5B210@yahoo.com> References: <20210503153442.GB37236@www.zefox.net> <3E0512C0-7667-44C4-B64B-501783C5B210@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 03, 2021 at 11:24:02AM -0700, Mark Millard wrote: > > > On 2021-May-3, at 08:34, bob prohaska <fbsd at www.zefox.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210503223811.GC37236>