Date: Fri, 21 Jan 2022 15:32:31 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Ping troubles, was Re: Troubles building world on stable/13 Message-ID: <AC9811FC-6F97-42B9-9A81-7BDF842C9E2E@yahoo.com> In-Reply-To: <20220121215740.GA29220@www.zefox.net> References: <20220121031601.GA26308@www.zefox.net> <FA290367-D4B6-463D-AC67-64F224B3C227@yahoo.com> <20220121163445.GA28761@www.zefox.net> <2CABF256-CC55-4449-80CB-A3DFF9B4B7A7@yahoo.com> <20220121215740.GA29220@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jan-21, at 13:57, bob prohaska <fbsd@www.zefox.net> wrote: > On Fri, Jan 21, 2022 at 12:54:02PM -0800, Mark Millard wrote: >> after the id for what you are trying to build. >>=20 >> I have multiple source trees around, one for stable/13 . >> I use: >>=20 >> # more ~/fbsd-based-on-what-commit.sh=20 >> #! /bin/sh >> branch=3D"`git $* branch --show-current`" \ >> && echo "branch: $branch" \ >> && base=3D"`git $* merge-base freebsd/$branch HEAD`" \ >> && git $* log --oneline --no-color $base..HEAD \ >> && base_date=3D"`TZ=3DUTC git $* log --format=3Dfuller = --date=3Diso-local --no-color $base^..$base | grep CommitDate:`" \ >> && echo "merge-base: $base" \ >> && echo "merge-base: $base_date" \ >> && git $* log --oneline --no-color $base^..$base \ >> && echo "n`git $* rev-list --first-parent --count $base` = (--first-parent --count for merge-base)" >>=20 >> like so (for my stable/13 source tree, your path would >> likely be /usr/src instead): >>=20 > Thank you, the script reports: > branch: stable/13 > merge-base: d7b156672a48c37e1b8ce9b4ae28a46ecea55412 > merge-base: CommitDate: 2022-01-21 15:58:11 +0000 > d7b156672a4 (HEAD -> stable/13, freebsd/stable/13) zone.9: Remove = documentation of non-existent NUMA configuration flags > n249092 (--first-parent --count for merge-base) >=20 >=20 >>=20 >>>> Any console messages? dmesg -a output of interest? >>>> /var/log/messasges content of interest? >>>>=20 >>>=20 >>> Nothing obvious, in particular no "killed, out of swap" type = messages. >>>=20 >>>> Any messages of interest somewhat earlier in the >>>> buildworld.log ? >>>>=20 >>>=20 >>> Not that I can recognize. I started to put the buildworld.log file = on my >>> public webserver and was surprised to find that sftp didn't connect. >>> Trying to connect from the server to pelorus so as to use get failed >>> likewise.=20 >>>=20 >>> Next I tried to ping from the webserver to the stable/13 machine, no = answer. >>> Finally I started a ping from stable/13 to the webserver, at which = point >>> the opposing ping session woke up. That seems most strange. >>>=20 >>> With ping running once per second from webserver to stable/13 = usually a=20 >>> single packet is returned. Starting a ping in the reverse direction = at >>> 10 second intervals _usually_ results in a single packet reply; = occasionally >>> none or two. It isn't entirely consistent.=20 >>>=20 >>> Both machines are on wired public networks, so between them there is = no >>> NAT involved. Packet losses correspond roughly to rate; Most of the >>> 1-second packets are lost, most of the 10-second packets are = answered. =20 >>>=20 >=20 > I take it the ping behavior doesn't impress you as odd? I thought it=20= > most strange. Odd, but I did not see how it fit with the original problem and I'm unsure what to comment on about it directly beyond our earlier ssh related exchange, where I'd noted for the icmp_seq values in the ping output that you had then listed: QUOTE The way I read the below, icmp_seq=3D0 and icmp_seq=3D1 took more time than icmp_seq=3D58 and icmp_seq=3D117 and the like. But lots of icmp_seq values did not complete a round trip. Also: 58-1 =3D=3D 57 176-118 =3D=3D 58 235-177 =3D=3D 58 It looks like the start of a pattern already. END QUOTE. >>>> Does the problem repeat via using the files: >>>>=20 >>>> /tmp/gmock-all-836ef8.cpp >>>> /tmp/gmock-all-836ef8.sh >>>>=20 >>>=20 >>> Not sure how to try that, but it seems to repeat on a simple repeat = of >>> the buildworld command. >>=20 >> The .sh compiles the .cpp using the options involved when the >> failure happened. Copy the files to an appropriate place and >> then run the .sh script. >>=20 >>>> on that RPi3? Elsewhere that has more resources, such >>>> as more RAM? >>>=20 >>> I've only this one machine running stable/13, but a Pi3 and a Pi4 = running >>> -current don't seem to be affected, nor do several pi2's running = stable/12 >>> ARMv7. >>=20 >> System-clang is 13 on all those for now. The .sh and .cpp test >> should be executable on all the machines. >>=20 >>> The troublesome machine has been updated many times using git pull = followed >>> by buildworld -DWITH_META_MODE. Might it be necessary to = occasionally run >>> one of the cleaning targets? In other words, could META_MODE permit = obsolete=20 >>> files to persist across builds and reboots?=20 >>>=20 >>=20 >> I only rarely rm -fr in a build tree area to start from scratch. >> Nothing wrong with such an experiment. >>=20 >=20 > Cleanout of /usr/obj looks like the next thing to try. There don't > seem to be any folks having similar difficulties so it's probably > some artifact of this machine's history. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC9811FC-6F97-42B9-9A81-7BDF842C9E2E>