From nobody Mon Jul 04 15:28:34 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7E1F3C7B6E5 for ; Mon, 4 Jul 2022 15:28:40 +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 4Lc8pb4Kxtz3plQ for ; Mon, 4 Jul 2022 15:28:39 +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 264FSZtG003685 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 4 Jul 2022 08:28:35 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 264FSY7L003684; Mon, 4 Jul 2022 08:28:34 -0700 (PDT) (envelope-from fbsd) Date: Mon, 4 Jul 2022 08:28:34 -0700 From: bob prohaska To: Karl Denninger Cc: freebsd-arm@freebsd.org Subject: Re: 13.1R problems on Pi3 Message-ID: <20220704152834.GA1771@www.zefox.net> References: <20220704003639.GA1165@www.zefox.net> <8820A9EC-A25E-4D0A-9F8F-52114E58B66F@yahoo.com> <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c377413-9430-54d2-3f92-1215055ca30a@denninger.net> X-Rspamd-Queue-Id: 4Lc8pb4Kxtz3plQ 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.10 / 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(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm]; R_SPF_NA(0.00)[no SPF record]; 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]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Jul 03, 2022 at 10:36:35PM -0400, Karl Denninger wrote: > > This is crossbuilt but... > > $ uname -v > FreeBSD 13.1-STABLE #0 stable/13-n250683-e44e611e31c: Fri May?? 6 10:47:17 > EDT 2022 karl@NewFS.denninger.net:/work/OBJ/ARM64-13/obj/work/CrossBuild-13.1STABLE/arm64.aarch64/sys/GENERIC > > $ uptime > 10:27PM?? up 49 days,?? 7:10, 1 user, load averages: 0.14, 0.15, 0.13 > > Ping both for Ipv4 and v6 (along with everything else) works fine. > That makes it unlikely the omission of DHCP services on my machines accounts of lack of ping and ssh response. Can any sense be made of the few ping responses obtained when ntp is coming up? It's looks as if something happens after ntp runs that blocks subsequent network traffic, but why starting an outbound ping should partly unblock things is obscure to me. To answer Mark's question about my network setup, I'm using an ISP assigned network block of addresses, 50.1.20.31-50.1.20.24. All are usable, there's no DHCP server. I assign one address to my router for my LAN, the rest are taken by FreeBSD hosts. There are three Pi2s running stable/12, one Pi2 running -current, (presently) two Pi3s running stable/13 and one Pi4 running -current. So far only the Pi3s are displaying network problems. Network traffic enters my premises via DSL, connects to a switch and thence to the router and hosts. A second switch chained off the first provides connection to one Pi3 and the Pi4. The other Pi3 is on the first switch. So, one Pi3 is on the first switch, the other is on the second, both Pi3s are acting strange and the Pi4 works fine. So, I don't think it's the second switch. Thanks for writing! bob prohaska