# Serial TTY hangs sometimes on R-Pi B with 11.1 Stable



## gardner (Nov 10, 2017)

This is a bit of an annoyance but probably there is an underlying bug in the PL011 driver.

I have a R-Pi B running FreeBSD-11.1-STABLE-arm-armv6-RPI-B-20170925-r323968.  I have a getty on /dev/ttyu0 which is the R-Pi Primecell PL011.  When a user whose shell is /bin/csh logs into this TTY, all is well.  When a user whose shell is /bin/sh does, the process hangs before the prompt appears.  In an effort to get a core dump to track the problem down, I discovered that CTRL-\ SIGQUIT unblocks the process and all is well again.

Something in the man pipeline -- probably /usr/bin/less --- has the same behaviour.

I suspect there is some IOCTL that /bin/sh does on the controlling TTY that has a dodgy implementation in dev/uart/uart_dev_pl011.c.  If this is a known-issue, can anyone mention the bug or discussion?

Thanks.


----------



## Manuell (Mar 11, 2018)

No solution yet, but I found something that at least looks like the same problem:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200445

Comments 6 and 7 show a change in /etc/ttys that seems to be working in this case...


----------



## SirDice (Mar 12, 2018)

It probably also depends on the type of null-modem cable used. A lot of the cheap cables are 3 wire (RxD, TxD, GND), hardware flow control expects 5 wire (RxD, TxD, RTS, CTS, GND). You can even have more connections for DTR, DTS and CD. 

It's odd there's an apparent difference between csh(1) and sh(1) though. I would expect hardware or software flow control to work irrespective of the shell being used.


----------

