On 11/24/18 7:32 PM, Florian Zumbiehl wrote:
Hi,
Requested baud setting looks odd to me. Maybe related to this
--keep-baud flag in "/sbin/agetty -o -p -- \u --keep-baud
115200,38400,9600 ttyUSB0 vt220"?
Well, what is the baud rate of the other side? It seems a bit strange
that ...
115200.
1. serial-getty@ttyUSB0.service disabled
speed 9600 baud; rows 0; columns 0; line = 0;
... this works ...
3. serial-getty@ttyUSB0.service disabled && picocom -b 115200 /dev/ttyUSB0
speed 115200 baud; rows 0; columns 0; line = 0;
... and this works as well?!
I think before debugging a potential problem with the new flow control
feature, it would be a good idea to first make sure the baud rate is
configured correctly. Maybe agetty's baud rate selection is somehow
influenced by the new flow control support? I don't see how it would, and
maybe that's still a bug somehow, but I suspect that there is no flow
control problem at all, but rather it's just a baud rate mismatch that
prevents communication.
I went debugging the commit and pl2303_set_termios() a bit. I noticed
that the tty_termios_hw_change() returns zero when starting the getty
service that keeps the existing baud. Same goes with the plain "picocom
/dev/ttyUSB0" without specifying the baud which also works before commit
7041d9c3f01b.
For both cases ixon_change is true so the pl2303_termios_change()
returns true causing the pl2303_set_termios() to go forward doing the
baudrate (incorrectly 9600 instead of 115200) etc. changes which doesn't
happen before commit 7041d9c3f01b.
This incorrect 9600 baud made me thinking could it be possible that
driver doesn't initialize some structure with the current settings the
kernel console is using? Would this also explain also why
"stty -a -F /dev/ttyUSB0" shows 9600 when kernel console is certainly
using 115200 (after boot before running neither agetty or picocom)?
I verified the same setup using legacy 8250 uart and with it the
"stty -a -F /dev/ttyS0" shows correctly 115200 baud.
--
Jarkko
