Re: USB-serial adapter suggestions needed

On Jan 12, 2024, at 13:37, bob prohaska <fbsd@www.zefox.net> wrote:
> 
> 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:
>> 
>>> On Fri, Jan 12, 2024 at 10:34:11AM -0800, Mark Millard wrote:
>>>> 
>>>> If you did not specify the signal explicitly, you tried:
>>>> 
>>>>    15    SIGTERM          terminate process    software termination signal
>>>> 
>>>> (I'm not claiming all those "terminate process" signals are
>>>> likely to be involved. But SIGTERM is need not be involved
>>>> at all.)
>>>> 
>>>>> Both the ssh connection from workstation to terminal
>>>>> server and the su to root needed to run tip survive.
>>>>> 
>>>>> I should apologize for not testing this sooner, it
>>>>> was a very easy experiment. If you think of useful
>>>>> variations please indicate them.
>>>> 
>>>> See above, in particular SIGHUP .
>>>> 
>>> 
>>> Just tried SIGHUP several times. The ssh connection didn't
>>> disconnect. There were also no reports about overriding stale
>>> locks. 
>>> 
>>> Using SIGKILL reported:
>>> 
>>> login: Killed
>>>            root@nemesis:/home/bob # 
>>> root@nemesis:/home/bob # tip ucom
>>> Stale lock on cuaU0 PID=45604... overriding.
>>> connected
>>> 
>>> 
>>> FreeBSD/arm (ns2.zefox.net) (ttyu0)
>>> but the ssh session and su survived.
>>> 
>>> 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.
>>> 
>>> Not sure what to make of this, except that ssh survives
>>> exit of tip, graceful or not.  
>> 
>> Remember:
>> 
>> Jan 10 14:29:48 nemesis kernel: ucom_close: tp=0xffffa00001979800
>> Jan 10 14:29:48 nemesis kernel: ucom_shutdown: 
>> Jan 10 14:29:48 nemesis kernel: ucom_dtr: onoff = 0
>> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=0x00, off=0x01
>> Jan 10 14:29:48 nemesis kernel: ucom_rts: onoff = 1
>> Jan 10 14:29:48 nemesis kernel: ucom_line_state: on=0x02, off=0x00
>> Jan 10 14:29:48 nemesis kernel: ucom_cfg_close: 
>> Jan 10 15:04:07 nemesis su[35181]: bob to root on /dev/pts/4
>> 
>> (and what was somewhat before and somewhat after)?
>> 
>> What were those messages like (if any) for each of the types of kills?
> 
> Far as I can tell they're the same following ucom_shutdown. 
> Preceeding ucom_shutdown it looks like the sequence of messages
> varies a little, but obvious things like the big hex numbers
> are clearly indentical. 
> 
> If you've got something in mind please tell me what it is and I'll 
> be able to look more intelligently.

So each of the signals result in a full

ucom_close: tp=. . .
. . .
ucom_cfg_close:

sequence?

If yes, that answers my question. Otherwise I'd like to 
see the variations.

===
Mark Millard
marklmi at yahoo.com