On Mon, Nov 26, 2018 at 02:29:53PM +0200, Jarkko Nikula wrote: > 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"? That indeed seems to be the case. > > 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)? Correct. The USB-serial console code has never reported the actual settings used, but with the pl2303 flow control change this now obviously broke your setup. Judging from your reports, including the stty outputs, it seems like the getty is trying to disable flow control while keeping the baud rate unchanged. Prior to the pl2303 change this was a noop which left the baud rate unchanged, but now you end up with the driver default 9600 baud. > I verified the same setup using legacy 8250 uart and with it the > "stty -a -F /dev/ttyS0" shows correctly 115200 baud. Right, the serial console correctly updates the terminal settings, unlike the USB-serial console code. I've come up with a non-intrusive fix which fixes the incorrectly reported terminal settings. Would you mind giving it a try? Thanks, Johan
