Re: Call for participation
Please count me in for this. Thank you. Amar.
Re: git commit for WITH_DETECT_TZ_CHANGES breaks date, et al
On Tue, 14 Sep 2021 10:37:36 +0200 Michael Gmelin wrote: > > On Tue, 14 Sep 2021 09:02:46 + > Gary Jennejohn wrote: > > > On Mon, 13 Sep 2021 21:30:02 -0400 > > Michael Butler via freebsd-current > > wrote: > > > > > After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to > > > recognize any configured timezone when WITH_DETECT_TZ_CHANGES is > > > not set. > > > > > > For example .. > > > > > > imb@vm01:/home/imb> date > > > Tue Sep 14 01:25:57 2021 > > > > > > Every other daemon also thinks it's running in UTC+0 :-( > > > > > > When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in > > > /etc/src.conf, the output is (for me) .. > > > imb@vm01:/usr/src/lib/libc> date > > > Mon Sep 13 21:28:29 EDT 2021 > > > > > > > Same here. After instaling the new world this morning I was suddenly > > in UTC instead of CEST (2 hours difference). > > > > Thanks for the fix :-) > > Before reading your message, I (ironically) wanted to tell you about > your email's date header containing the wrong timezone ^_^ > > -m > > -- > Michael Gmelin > Just a thought (not at all tested), but... #definechange_in_tz(X) 0 in line 393 of localtime.c should be #definechange_in_tz(X) 1 if I understand correctly. Or remove line 392 and 393 with guarding added line 470 though 485 with #ifdef DETECT_TZ_CHANGES. Old behaviour never returns there. I suspect current code without defining WITH_DETECT_TZ_CHANGES=yes in /etc/src.conf make first tzload() call do nothing and forth fallback to UTC. -- Tomoaki AOKI
Re: recent head having significantly less "avail memory"
On Tue, Sep 14, 2021 at 12:25:55AM +0200, Guido Falsi wrote: > On 14/09/21 00:12, Konstantin Belousov wrote: > > On Mon, Sep 13, 2021 at 10:07:46PM +0200, Guido Falsi wrote: > > > On 13/09/21 19:08, Konstantin Belousov wrote: > > > > On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via > > > > freebsd-current wrote: > > > > > Hi, > > > > > > > > > > I updated head recently and today I noticed a difference which looks > > > > > wrong. > > > > > > > > > > At boodt the new head shows signifcantly less avail memory than > > > > > before, > > > > > around 3 GiB less. > > > > > > > > > > I moved from commit 71fbc6faed6 [1] where I got: > > > > > > > > > > Aug 28 22:03:03 marvin kernel: real memory = 17179869184 (16384 MB) > > > > > Aug 28 22:03:03 marvin kernel: avail memory = 16590352384 (15821 MB) > > > > > > > > > > to commit 7955efd574b [2] where I get: > > > > > > > > > > Sep 13 10:44:40 marvin kernel: real memory = 17179869184 (16384 MB) > > > > > Sep 13 10:44:40 marvin kernel: avail memory = 13298876416 (12682 MB) > > > > > > > > > > I'm seeing this on multiple machines. > > > > > > > > > > Unluckily bisecting and trying an older loader.efi in sseparate tests > > > > > did > > > > > not give me any more insight. > > > > > > > > > > The recent changes to efi loader, starting with commit 6032b6ba9596 > > > > > [3] look > > > > > like a possible trigger to this, but I have been unable to confirm it. > > > > > > > > > > Any suggesstions on how to proceed to debug thiss? ANy idea what a > > > > > fix could > > > > > be? > > > > > > > > Is this UEFI or bios boot? > > > > Provide verbose dmesg for old and new boots on the same machine. > > > > For UEFI boot, show output of 'sysctl machdep.efi_map', again for old > > > > and new boots. > > > > > > > > > > I shared the data you request here: > > > > > > https://www.madpilot.net/cloud/s/ENW5zF7jfmrmFeG > > > > Thanks. > > > > If you do on the loader prompt for the new (AKA bad) kernel > > copy_staging enable > > and then boot, does the report of avail memory becomes good? > > > > Yes, it works as expected, that is reports the amount of memory I expect: > > Sep 14 00:24:50 marvin kernel: real memory = 17179869184 (16384 MB) > Sep 14 00:24:50 marvin kernel: avail memory = 16590356480 (15821 MB) Please try https://reviews.freebsd.org/D31958
Re: src/lib/libgcc_s needs mv /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a
Hi stable@ & current@,
Apologies for a cross post, as
a fault reported May 2019 on current, is still breaking on stable Sept 2021.
2019 Refs:
Subject: lib/libgcc_s fails on make all after make world succeeds
https://lists.freebsd.org/pipermail/freebsd-current/2019-May/073440.html
From: Julian H. Stacey jhs at berklix.com
Sun May 19 21:30:10 UTC 2019
https://lists.freebsd.org/pipermail/freebsd-current/2019-May/073442.html
From: Dimitry Andric dim at FreeBSD.org
Date: Sun, 19 May 2019 23:54:18 +0200
2021 Ref:
Subject: src/lib/libgcc_s needs mv /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a
https://lists.freebsd.org/archives/freebsd-stable/2021-September/000225.html
From: From: Julian H. Stacey
Dimitry suggested maybe a rare race condition, so I just started a
make -B -j 1 world
It will take a while, old machines here, (maybe that's
what's exposing a race condition not seen on faster boxes ?)
A 2nd speculation was I may be missing symbolic links ?
Last year & maybe earlier, I had problems from missing symbolic links,
when I was fetching src/ with a (since fixed, Sept 2020) ctm; But my src-12/
is new, not CTM supplied, but from
cd ~/git/`hostname -s`/src-12
git clone -o freebsd -b stable/12 https://git.freebsd.org/src.git src
cd ~/git/`hostname -s`/src-12/src
git pull --ff-only
The only symbolic links I have are in
src-cur/ contrib/bc/ contrib/tcpdump/ sys/contrib/openzfs/
src-12/ contrib/bc/ contrib/tcpdump/
So lack of symbolic links is not the problem, unless someone sees more links
I dont have, if one of you could perhaps kindly check ? with eg
cd /usr/src; find -s . -type l | sort | grep -v sys/amd64/compile \
grep -v contrib/bc | grep -v contrib/tcpdump | grep -v sys/contrib/openzfs
Anyone else seen problems making lib/libgcc_s ?
Any other ideas what else to check ?
I've already checked as in my last post appended.
I'm now checking for any files only under root or only under a tree
installed by setenv DESTDIR .
Suggestions welcome please ?
{==
To: FreeBSD-STABLE Mailing List
Subject: src/lib/libgcc_s needs mv /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a
Date: Sun, 12 Sep 2021 14:53:58 +0200
Hi all,
Anyone else seen this ? After
cd /usr/src ; make install
this fails
cd /usr/src/lib/libgcc_s ; make
until a manual
mv /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a\
/usr/obj/usr/src/amd64.amd64/lib/libc/libc.a.MV
when
cd /usr/src ; make all ; make install
can run OK, but then again needs another 'mv'.
Identical: md5 /usr/obj/usr/src/amd64.amd64/lib/libc/libc.a* /usr/lib/libc.a
Maybe its changing where linking from ? **
I've had this on & off for months I think, on multiple hardware, but possibly
just 12.2-STABLE,
it's still so with a stable src/ fetched a day or ago with git pull --ff-only
To help simplify debug, I have no /etc/src.conf /etc/make.conf
I also stripped my env with http://berklix.com/~jhs/bin/.csh/unsetenv.csh
source `which unsetenv.csh`
Remaining: DESTDIR DISPLAY HOSTDISPLAY PATH TERM TERMCAP TERMPATH
None of that helps.
I am running a 12.2 self built system, uncustomised src/, no kernel modules,
uname -a
FreeBSD fire.js.berklix.net 12.2-RELEASE FreeBSD 12.2-RELEASE
#0: Sat May 22 20:41:18 CEST 2021
j...@fire.js.berklix.net:/1s4/ftp/pri/FreeBSD/releases/12.2-RELEASE/generic/src/sys/amd64/compile/GENERIC
amd64
with the exception of /boot/kernel which is 12.2-RELEASE as for some unknown
reason I cant boot a local compiled or cross compiled 12.2-STABLE kernel
(I'm still investigating that presumed un-associated issue)
** Here's a script log :
{---
===> etc (install)
===> etc/sendmail (install)
cd /usr1/src/share/man; make makedb
makewhatis /usr/share/man
makewhatis /usr/share/openssl/man
cd /usr/src/lib/libgcc_s ; make
cat /usr1/src/lib/libgcc_s/Symbol.map /usr1/src/lib/libgcc_s/SymbolDefault.map
| cpp - - | awk -v vfile=/usr1/src/lib/libgcc_s/Versions.def -f
/usr/share/mk/version_gen.awk > Version.map
building shared library libgcc_s.so.1
cc -nodefaultlibs -Wl,--version-script=Version.map -shared -Wl,-x
-Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libgcc_s.so.1.full
-Wl,-soname,libgcc_s.so.1 `NM='nm' NMFLAGS='' lorder i386/fp_mode.pico
absvdi2.pico absvsi2.pico absvti2.pico addvdi3.pico addvsi3.pico addvti3.pico
apple_versioning.pico ashldi3.pico ashlti3.pico ashrdi3.pico ashrti3.pico
bswapdi2.pico bswapsi2.pico clear_cache.pico clzdi2.pico clzsi2.pico
clzti2.pico cmpdi2.pico cmpti2.pico ctzdi2.pico ctzsi2.pico ctzti2.pico
divdc3.pico divdi3.pico divmoddi4.pico divmodsi4.pico divsc3.pico divsi3.pico
divtc3.pico divti3.pico divxc3.pico enable_execute_stack.pico eprintf.pico
extendhfsf2.pico ffsdi2.pico ffssi2.pico ffsti2.pico fixdfdi.pico fixdfti.pico
fixsfdi.pico fixsfti.pico fixunsdfdi.pico fixunsdfsi.pico fixunsdfti.pico
fixunssfdi.pico fixunssfsi.pico fixunssfti.pico
Re: Call for participation
Hi Warner, Please count me in too. -Merv
Re: git commit for WITH_DETECT_TZ_CHANGES breaks date, et al
On Tue, 14 Sep 2021 09:02:46 + Gary Jennejohn wrote: > On Mon, 13 Sep 2021 21:30:02 -0400 > Michael Butler via freebsd-current > wrote: > > > After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to > > recognize any configured timezone when WITH_DETECT_TZ_CHANGES is > > not set. > > > > For example .. > > > > imb@vm01:/home/imb> date > > Tue Sep 14 01:25:57 2021 > > > > Every other daemon also thinks it's running in UTC+0 :-( > > > > When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in > > /etc/src.conf, the output is (for me) .. > > imb@vm01:/usr/src/lib/libc> date > > Mon Sep 13 21:28:29 EDT 2021 > > > > Same here. After instaling the new world this morning I was suddenly > in UTC instead of CEST (2 hours difference). > > Thanks for the fix :-) Before reading your message, I (ironically) wanted to tell you about your email's date header containing the wrong timezone ^_^ -m -- Michael Gmelin
Re: git commit for WITH_DETECT_TZ_CHANGES breaks date, et al
On Mon, 13 Sep 2021 21:30:02 -0400 Michael Butler via freebsd-current wrote: > After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to recognize > any configured timezone when WITH_DETECT_TZ_CHANGES is not set. > > For example .. > > imb@vm01:/home/imb> date > Tue Sep 14 01:25:57 2021 > > Every other daemon also thinks it's running in UTC+0 :-( > > When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in /etc/src.conf, the > output is (for me) .. > > imb@vm01:/usr/src/lib/libc> date > Mon Sep 13 21:28:29 EDT 2021 > Same here. After instaling the new world this morning I was suddenly in UTC instead of CEST (2 hours difference). Thanks for the fix :-) -- Gary Jennejohn
