Re: Stable/14 dropping ssh connections to FT232 usb-serial adapter

On Oct 26, 2023, at 07:42, bob prohaska <[email protected]> wrote:

> On Fri, Sep 29, 2023 at 11:12:00AM -0700, bob prohaska wrote:
>> A stable/14 install on a Pi2 v1.1 (armv7) host seems to
>> work quite well, apart from dropping ssh connections when
>> used to run a cu or tip session to an FT232 usb-serial
>> adapter. Ssh connections to interactive shells seem to
>> remain up indefinitely, but drop within a couple of hours
>> (between the same hosts) when used to run cu or tip.
> 
> Now that ucom supports debugging at the USB end of the
> connection a little more information is offered. At the
> armv7 USB end of the link the console reports:
> 
> login: ucom_inwakeup: tp=0xd6c38800
> ucom_inwakeup: tp=0xd6c38800
> ucom_inwakeup: tp=0xd6c38800
> ucom_inwakeup: tp=0xd6c38800
> ucom_inwakeup: tp=0xd6c38800
> ucom_inwakeup: tp=0xd6c38800
> ucom_inwakeup: tp=0xd6c38800
> ucom_inwakeup: tp=0xd6c38800
> ucom_inwakeup: tp=0xd6c38800
> ucom_close: tp=0xd6c38800
> ucom_shutdown: 
> ucom_dtr: onoff = 0
> ucom_line_state: on=0x00, off=0x01
> ucom_rts: onoff = 1
> ucom_line_state: on=0x02, off=0x00
> ucom_cfg_close:

To me this just looks like the process using ucom for this
just quit using it for this, closing the use down in a normal
manor. The question likely becomes what is going on in that
more overall context. It would be good to figure out what
sequence initiated what lead to ucom_close, not that I've a
clue for a good way to get that information.

I've not seen anything that I'd guess to be an error visible
via the USB messages. (But I'm no expert.)

===
Mark Millard
marklmi at yahoo.com