Date: Fri, 27 Oct 2023 09:54:53 -0700 From: bob prohaska <fbsd@www.zefox.net> To: freebsd-arm@freebsd.org Subject: Releng/14.0 dropping ssh connections to USB-serial adapter Message-ID: <ZTvrXXpzPW89DxFP@www.zefox.net>
next in thread | raw e-mail | index | archive | help
It appears that releng/14.0 is still dropping ssh connections to a USB-serial adapter, though the problem seems absent now on -current. Usbconfig reports ugen1.4: <FTDI USB - Serial> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (90mA) The USB-end host is a Pi2 v1.1 running armv7, the usb adapter is an FTDI FT232 and the serial end is the serial console of a Pi3. The adapter is plugged directly into the Pi, no USB hub is used. The root filesystem is on a USB mechanical hard disk connected via a powered hub and booting is vi microSD "bootcode.bin" mode. With USB debugging turned on quite a lot of output is generated, the only part I recognize is a "ucom_shutdown" on the USB end's console. That makes termination of the serial connection look intentional. Why the ssh connection to the host exits entirely isn't evident to me. When the connection has dropped, restoring it is straightforward: bob@generic:~ % su Password: # tip ucom Stale lock on cuaU0 PID=1201... overriding. connected authentica [I didn't type this, it somehow got into the data stream] Password: [I simply hit Enter] Login incorrect login: It looks as if part of the serial console login prompt has somehow leaked into the _inbound_ data stream. This is seen on other Pi hosts in my collection, too, but seems unrelated to connections dropping. Meanwhile, the console of the USB-end host reports: login: Oct 27 08:21:23 generic su[3278]: bob to root on /dev/pts/0 ucom_open: tp = 0xd6c3f400 ucom_cfg_open: ucom_dtr: onoff = 1 ucom_line_state: on=0x01, off=0x00 ucom_rts: onoff = 1 ucom_line_state: on=0x02, off=0x00 ucom_ring: onoff = 0 ucom_line_state: on=0x00, off=0x08 ucom_break: onoff = 0 ucom_line_state: on=0x00, off=0x04 ucom_status_change: ucom_param: sc = 0xd6c3f858 ucom_dtr: onoff = 1 ucom_line_state: on=0x01, off=0x00 ucom_rts: onoff = 1 ucom_line_state: on=0x02, off=0x00 ucom_ioctl: cmd = 0x402c7413 ucom_ioctl: cmd = 0x802c7416 ucom_outwakeup: sc = 0xd6c3f858 ucom_outwakeup: sc = 0xd6c3f858 ucom_get_data: cnt=13 ucom_inwakeup: tp=0xd6c3f400 ucom_inwakeup: tp=0xd6c3f400 ucom_get_data: cnt=0 ucom_ioctl: cmd = 0x2000740d ucom_ioctl: cmd = 0x402c7413 ucom_ioctl: cmd = 0x802c7416 ucom_inwakeup: tp=0xd6c3f400 ucom_inwakeup: tp=0xd6c3f400 ucom_param: sc = 0xd6c3f858 ucom_ioctl: cmd = 0x8004667e ucom_ioctl: cmd = 0x8004667d ucom_get_data: cnt=0 ucom_inwakeup: tp=0xd6c3f400 ucom_inwakeup: tp=0xd6c3f400 ucom_inwakeup: tp=0xd6c3f400 ucom_outwakeup: sc = 0xd6c3f858 ucom_get_data: cnt=1 ucom_get_data: cnt=0 ucom_inwakeup: tp=0xd6c3f400 Hitting Enter restores the console login prompt. The connections usually drop over the span of a few hours, seemingly a bit faster when the host is active, as when running buildworld, but I've not tested carefully. This connection dropped after a bit over an hour. The output generated is huge on both ends so I'll place it at http://www.zefox.net/~fbsd/rpi2/ssh_drops_usb_serial Suggestions for betters tests are welcome! Thanks for reading, bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZTvrXXpzPW89DxFP>