Re: USB-serial adapter suggestions needed

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 07 Jan 2024 16:48:36 UTC
On Jan 6, 2024, at 19:00, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> On Jan 6, 2024, at 18:36, bob prohaska <fbsd@www.zefox.net> wrote:
>> 
>> On Sat, Jan 06, 2024 at 11:44:49PM +0000, Marcin Cieslak wrote:
>>>> On Fri, 5 Jan 2024, Mark Millard wrote:
>>>> 
>>>> I also request to again list the exact content of the two
>>>> config.txt files --and again every time they are changed during
>>>> this investigation.
>>> 
>>> I second this. There is way too much text in this conversation
>>> and not enough data. It also does not help if every system is somewhat
>>> different.
>> 
>> Unfortunately, the systems simply are different. Four Pi2
> 
> Please differentiate RPi2B v1.1 (armv7) from v1.2 (aarch64).

I meant that to be a general request to never reference just
RPi2B. The v1.1 vs. v1.2 was an unfortunate marketing naming
for the armv7 vs. aarch64 change that ends up needing such
extra text to give the proper context.

> I suggest armv7 use the snapshot armv7’s config.txt as its
> config.txt prefix.
> 
>> , two Pi3,
>> one Pi4. I'll try to make the config.txt files on the Pi3s match
>> better when the present experiment is complete. The interconnection
>> of hosts is unique and, apparently, unusual. Not all of that is
>> relevant, but exatctly what part isn't yet obvious.
>> 
>>> 
>>> I have skimmed the peripherial documentation for one of the Broadcom
>>> chips (I think the one from Raspberry Pi 3) and it says that
>>> the speed of the mini uart depends on the CPU clock frequency.
>>> 
>>> I could imagine a situation when mini uart speed changes during
>>> downlocking the CPU.  There was suggestion to not use mini uart.
>>> Use the port where the frequency is not changing with the weather.
>>> 
>> 
>> Agreed, and I changed config.txt to set
>> dtoverly=disable-bt
>> on www.zefox.org (the console host) to force use of the PL011.
>> It didn't help detectably.
>> 
>>> I don't know how smart is the power management with powerd, but
>>> I could also imagine shutting down peripherials or stopping the UART
>>> clock as a potential power saving feature, so here you are.
>> 
>> No sign of that, but Mark posited that powerd might be causing
>> trouble with the terminal server (pelorus in this test). That
>> looks like a possibility. At the moment pelorus is without
>> powerd and it's holding a serial connection to www.zefox.org.
>> 
>> Meanwhile www.zefox.org is running powerd and buildworld
>> while being a terminal server to a Pi4 named nemesis.zefox.com
>> That connection has dropped twice so far today.
> 
> Interesting. You have not reported on nemesis.zefox.com ‘s config.txt
> content or powerd status. Also, which type of RPi* ?

If the chart you referenced is right for the issue: RPi4B. (Other
details about turned out to be in accurate at the time as I
remember, so the cross check seems appropriate.) If so, that
still leaves the status of powerd and the config.txt content
to publicly document.

Also, as I understand the reports, a system running both tip and
powerd ends up dropping the serial console connection at times.
A system running tip but not powerd does not drop the connection.

However, it might be that some form of test of a RPi* running
powerd and just tip and not ssh might be useful. Similarly for
a RPi* running powerd and just ssh, not tip. I'd expect that
the tip+powerd-ssh case (so no ssh) to fail and the
ssh+powerd-tip case (so: no tip) to not fail.

===
Mark Millard
marklmi at yahoo.com