Date: Fri, 12 Jan 2024 13:45:04 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: <B3EF009B-F7FE-4D2D-A266-D064C82E0DFF@yahoo.com> In-Reply-To: <ZaGxMA23qXBSC4Jj@www.zefox.net> References: <55AC6824-587D-4C67-B64B-2045A1112F69@yahoo.com> <ZZ8ugUkEDXbSUjZp@www.zefox.net> <041F74B4-3D44-4364-9EBD-9F21A4F3B313@yahoo.com> <ZaBLnwaHWYedwY9m@www.zefox.net> <902798B1-2B66-4ECD-BDAC-195C85066FE6@yahoo.com> <8B4C76B2-707E-4978-9CB3-5D547303A7E5@yahoo.com> <ZaFoY58MqBv9hX5b@www.zefox.net> <A1F3092A-CEB1-44DE-ADB3-F45113004B34@yahoo.com> <ZaGQfy8u2xYzztri@www.zefox.net> <482FA770-89E8-42E8-945E-B662AD564AFE@yahoo.com> <ZaGxMA23qXBSC4Jj@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 12, 2024, at 13:37, bob prohaska <fbsd@www.zefox.net> wrote: >=20 > On Fri, Jan 12, 2024 at 12:38:30PM -0800, Mark Millard wrote: >> On Jan 12, 2024, at 11:18, bob prohaska <fbsd@www.zefox.net> wrote: >>=20 >>> On Fri, Jan 12, 2024 at 10:34:11AM -0800, Mark Millard wrote: >>>>=20 >>>> If you did not specify the signal explicitly, you tried: >>>>=20 >>>> 15 SIGTERM terminate process software termination = signal >>>>=20 >>>> (I'm not claiming all those "terminate process" signals are >>>> likely to be involved. But SIGTERM is need not be involved >>>> at all.) >>>>=20 >>>>> Both the ssh connection from workstation to terminal >>>>> server and the su to root needed to run tip survive. >>>>>=20 >>>>> I should apologize for not testing this sooner, it >>>>> was a very easy experiment. If you think of useful >>>>> variations please indicate them. >>>>=20 >>>> See above, in particular SIGHUP . >>>>=20 >>>=20 >>> Just tried SIGHUP several times. The ssh connection didn't >>> disconnect. There were also no reports about overriding stale >>> locks.=20 >>>=20 >>> Using SIGKILL reported: >>>=20 >>> login: Killed >>> root@nemesis:/home/bob #=20 >>> root@nemesis:/home/bob # tip ucom >>> Stale lock on cuaU0 PID=3D45604... overriding. >>> connected >>>=20 >>>=20 >>> FreeBSD/arm (ns2.zefox.net) (ttyu0) >>> but the ssh session and su survived. >>>=20 >>> Finally, I tried SIGSTOP. Again, ssh and su stayed up, but >>> restarting tip reported: >>> all ports busy >>> Power-cycling the usb-serial adpter with usbconfig >>> isn't able to free the port. That's new-to-me behavior. >>> Deleting the /dev/cuaU0-related files didn't help. >>>=20 >>> Not sure what to make of this, except that ssh survives >>> exit of tip, graceful or not. =20 >>=20 >> Remember: >>=20 >> Jan 10 14:29:48 nemesis kernel: ucom_close: tp=3D0xffffa00001979800 >> Jan 10 14:29:48 nemesis kernel: ucom_shutdown:=20 >> Jan 10 14:29:48 nemesis kernel: ucom_dtr: onoff =3D 0 >> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x00, off=3D0x01 >> Jan 10 14:29:48 nemesis kernel: ucom_rts: onoff =3D 1 >> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=3D0x02, off=3D0x00 >> Jan 10 14:29:48 nemesis kernel: ucom_cfg_close:=20 >> Jan 10 15:04:07 nemesis su[35181]: bob to root on /dev/pts/4 >>=20 >> (and what was somewhat before and somewhat after)? >>=20 >> What were those messages like (if any) for each of the types of = kills? >=20 > Far as I can tell they're the same following ucom_shutdown.=20 > Preceeding ucom_shutdown it looks like the sequence of messages > varies a little, but obvious things like the big hex numbers > are clearly indentical.=20 >=20 > If you've got something in mind please tell me what it is and I'll=20 > be able to look more intelligently. So each of the signals result in a full ucom_close: tp=3D. . . . . . ucom_cfg_close: sequence? If yes, that answers my question. Otherwise I'd like to=20 see the variations. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B3EF009B-F7FE-4D2D-A266-D064C82E0DFF>