Date: Mon, 26 Feb 2018 11:31:21 -0700 From: Ian Lepore <ian@freebsd.org> To: bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org Subject: Re: Strange behavior from cu on armv7 Message-ID: <1519669881.91697.295.camel@freebsd.org> In-Reply-To: <20180226170320.GA21104@www.zefox.net> References: <20180226170320.GA21104@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2018-02-26 at 09:03 -0800, bob prohaska wrote: > Lately cu sessions (or something closely-related) have taken to > misbehaving on a Pi2 running -current. > > The situation is: > > ssh into armv7 host which has a pl2303 plugged into it > su to root > run cu -l cuaU0 -s 115200 to connect to the serial port of a Pi3 > > Most of the time the connection behaves normally. The pl2303 is prone > to locking up over time, seemingly faster (an hour) when the armv7 host > is loaded. In that case, unplugging and replugging the pl2303 aborts > the cu connection, which can then be restarted and again behaves normally. > > Lately, the unplug-replug cycle produces the normal recognition and > allows the cu session to be restarted, but no data is tranferred. > A "connected" prompt comes back, but there's no echo and no data. > Further unplug-replug attempts don't change anything. A reboot of > the armv7 host restores normal behavior. > > In a couple of cases unprintable characters displayed: > > root@www:/home/bob # cu -l cuaU0 -s 11520oo}root@www:/home/bob # cu -l cuaU0 -s 115200 > Connected > [hex characters didn't copy/paste] > > FreeBSD/arm64 (www.zefox.org) (ttyu0) > > login: � > > FreeBSD/arm64 (www.zefox.org) (ttyu0) > > login: > > And all is well, for now. > > Thanks for reading, and any ideas. > > bob prohaska Hmm. I've noticed for the past week or two (maybe longer) that if I connect to a wandboard serial console via an ftdi usb-serial and cu, and then I do "stty size 24 140" I get exactly the symptom you describe... no response to ^C or ^T, and neither un/replugging the ftdi nor closing and reopening the cu connection makes data flow in either direction until the arm board is rebooted. Ssh connections to the board continue to work fine and the system appears to be running fine, it's only the serial console that's dead. Killing the getty on the console doesn't help either, a new non-responsive getty starts up immediately. So, I guess all in all I have nothing much to offer here except a too- wordy "me too". -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1519669881.91697.295.camel>