From nobody Mon Oct 11 16:32:11 2021 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 882D11807CDE for ; Mon, 11 Oct 2021 16:32:18 +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 4HSkpn3z6pz3rXn for ; Mon, 11 Oct 2021 16:32:17 +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 19BGWCAI098630 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 11 Oct 2021 09:32:12 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 19BGWC9K098629 for freebsd-arm@freebsd.org; Mon, 11 Oct 2021 09:32:12 -0700 (PDT) (envelope-from fbsd) Date: Mon, 11 Oct 2021 09:32:11 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Oddities on Pi4 under -current Message-ID: <20211011163211.GA98507@www.zefox.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 X-Rspamd-Queue-Id: 4HSkpn3z6pz3rXn 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 [0.81 / 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_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[zefox.net]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.84)[0.839]; NEURAL_HAM_MEDIUM(-0.93)[-0.928]; 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 Recently a Pi4 running -current has been disconnecting certain ssh connections and is also slow initially responding to pings and ssh login attempts. The disconnects seem to happen only when the ssh session is used to establish a cu or tip connection to a usb-serial adapter, in this case a TTL232R. In either case the ssh/cu combination seems to exit, but no obvious error is reported beyond, for example, packet_write_wait: Connection to 192.168.1.11 port 22: Broken pipe at the originating end. The last log mention of the device appears to be sometime in the middle of the night: Oct 11 03:17:04 nemesis kernel: genet0: link state changed to DOWN Oct 11 03:17:04 nemesis kernel: genet0: link state changed to UP Oct 11 03:17:04 nemesis kernel: ums0 on uhub2 Oct 11 03:17:04 nemesis kernel: ums0: on usbus0 Oct 11 03:17:04 nemesis kernel: ums0: 3 buttons and [XYZ] coordinates ID=0 Oct 11 03:17:04 nemesis kernel: uftdi0 on uhub2 Oct 11 03:17:04 nemesis kernel: uftdi0: on usbus0 Oct 10 20:24:46 nemesis su[1323]: BAD SU bob to root on /dev/pts/0 Oct 10 20:24:53 nemesis su[1325]: bob to root on /dev/pts/0 Oct 10 23:28:27 nemesis su[1569]: bob to root on /dev/pts/1 Half a dozen other ssh connections from the originating host remain up to both the Pi4 and various Pi2 and Pi3 boxes. Only sessions involving the usb serial adapter seem affected. The slow response to ssh login appeared only in the past week or so. It isn't entirely reproducible, usually happening after idle time. The delay isn't more then five or ten seconds, but very noticeable. A ping after ~ 30 minutes idle time looks like this: bob@raspberrypi:~ $ ping 192.168.1.11 PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data 64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=5022 ms 64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=4004 ms 64 bytes from 192.168.1.11: icmp_seq=3 ttl=64 time=2964 ms 64 bytes from 192.168.1.11: icmp_seq=4 ttl=64 time=1925 ms 64 bytes from 192.168.1.11: icmp_seq=5 ttl=64 time=885 ms 64 bytes from 192.168.1.11: icmp_seq=6 ttl=64 time=3.49 ms 64 bytes from 192.168.1.11: icmp_seq=7 ttl=64 time=2.31 ms 64 bytes from 192.168.1.11: icmp_seq=8 ttl=64 time=2.15 ms 64 bytes from 192.168.1.11: icmp_seq=9 ttl=64 time=2.17 ms --- 192.168.1.11 ping statistics --- 9 packets transmitted, 9 received, 0% packet loss, time 151ms rtt min/avg/max/mdev = 2.151/1645.587/5021.971/1830.554 ms bob@raspberrypi:~ $ Pings to other hosts in my cluster do not exhibit the large initial delay, suggesting it isn't a network property. Any suggestions of things to check would be welcome. Thanks for reading, bob prohaska