From nobody Wed Dec 27 02:09:31 2023 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 4T0FT86dNZz54pLp for ; Wed, 27 Dec 2023 02:09:48 +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 4T0FT8065kz4Tdl for ; Wed, 27 Dec 2023 02:09:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=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; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 3BR29WUt031523 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 Dec 2023 18:09:32 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 3BR29V0I031522; Tue, 26 Dec 2023 18:09:31 -0800 (PST) (envelope-from fbsd) Date: Tue, 26 Dec 2023 18:09:31 -0800 From: bob prohaska To: ticso@cicely.de Cc: Marcin Cieslak , freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: References: <16864054-4os0-pq3p-7qp0-7299666908os@fncre.vasb> <55q37289-ss30-nq9o-7r31-086n999p394s@fncre.vasb> 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=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_THREE(0.00)[3]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[zefox.net]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4T0FT8065kz4Tdl X-Spamd-Bar: - On Tue, Dec 26, 2023 at 02:06:59AM +0100, Bernd Walter wrote: > On Tue, Dec 26, 2023 at 12:02:50AM +0000, Marcin Cieslak wrote: > > On Sun, 24 Dec 2023, bob prohaska wrote: > > > > > I do see what looks like noise on the serial lines, but only after a spontaneous > > > disconnect and only with FTDI adapters. When the serial connections are working > > > nothing resembling noise is seen. > > > > How does that noise look like? > It appears to be non-ascii. I can't get it to copy and paste in a way that's recognizable to me, but here's a sample anyway, taken from bob@pelorus:~ % uname -a FreeBSD pelorus 14.0-RELEASE-p4 FreeBSD 14.0-RELEASE-p4 #0 releng/14.0-n265400-4edf3b80733e: Wed Dec 27 20:21:26 PST 2023 bob@pelorus:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64: ........ # tip ucom connected FreeBSD/arm64 (www.zefox.org) (ttyu1) login: �������� Password: Login incorrect ........... The backslash letter pairs are clearly different, but they're displayed on a RasPiOS lxterminal window as a white oval with a dark question mark in the middle. Sometimes printable characters show up, but it doesn't look like my memory of a baudrate mismatch on a serial modem. Maybe that's just an artifact of modern character sets. > If the tip process was stopped by the ssh disconnect then the uart will fall > back to its default bps rate. > Some USB uarts still buffer received data in the chip itself, with the wrong > bps rate. > > > Did you try to run respective sshd daemons in the debug mode to log disconnects > > and possible their reason? I did, and didn't see anything recognizable as an error. It seemed the session just stopped. No errors, nothing. Whether it's ssh that stopped or tip that stopped seems to be the primary mystery. What I see is ssh stopping, but that may be more symptom than cause. Ssh sessions not involving tip/cu don't stop, at least not as often. Thanks for writing, bob prohaska > > > > -- > B.Walter https://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.