Re: Ping troubles, was Re: Troubles building world on stable/13

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.
>> 
>> I have multiple source trees around, one for stable/13 .
>> I use:
>> 
>> # more ~/fbsd-based-on-what-commit.sh 
>> #! /bin/sh
>> branch="`git $* branch --show-current`" \
>> && echo "branch: $branch" \
>> && base="`git $* merge-base freebsd/$branch HEAD`" \
>> && git $* log --oneline --no-color $base..HEAD \
>> && base_date="`TZ=UTC git $* log --format=fuller --date=iso-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)"
>> 
>> like so (for my stable/13 source tree, your path would
>> likely be /usr/src instead):
>> 
> 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)
> 
> 
>> 
>>>> Any console messages? dmesg -a output of interest?
>>>> /var/log/messasges content of interest?
>>>> 
>>> 
>>> Nothing obvious, in particular no "killed, out of swap" type messages.
>>> 
>>>> Any messages of interest somewhat earlier in the
>>>> buildworld.log ?
>>>> 
>>> 
>>> 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. 
>>> 
>>> 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.
>>> 
>>> With ping running once per second from webserver to stable/13 usually a 
>>> 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. 
>>> 
>>> 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.  
>>> 
> 
> I take it the ping behavior doesn't impress you  as odd? I thought it 
> 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=0 and icmp_seq=1 took
more time than icmp_seq=58 and icmp_seq=117 and the like.
But lots of icmp_seq values did not complete a round trip.

Also:

58-1   == 57
176-118 == 58
235-177 == 58

It looks like the start of a pattern already.
END QUOTE.

>>>> Does the problem repeat via using the files:
>>>> 
>>>> /tmp/gmock-all-836ef8.cpp
>>>> /tmp/gmock-all-836ef8.sh
>>>> 
>>> 
>>> Not sure how to try that, but it seems to repeat on a simple repeat of
>>> the buildworld command.
>> 
>> 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.
>> 
>>>> on that RPi3? Elsewhere that has more resources, such
>>>> as more RAM?
>>> 
>>> 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.
>> 
>> System-clang is 13 on all those for now. The .sh and .cpp test
>> should be executable on all the machines.
>> 
>>> 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 
>>> files to persist across builds and reboots? 
>>> 
>> 
>> I only rarely rm -fr in a build tree area to start from scratch.
>> Nothing wrong with such an experiment.
>> 
> 
> 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.



===
Mark Millard
marklmi at yahoo.com