Date: Sat, 17 Aug 1996 09:34:19 +1000 From: Bruce Evans <bde@zeta.org.au> To: freebsd-hackers@freefall.freebsd.org, ponds!rivers@dg-rtp.dg.com Subject: Re: more general info on SIO problems in 2.1.5. Message-ID: <199608162334.JAA07420@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
Originally-To: ponds!freefall.cdrom.com!freebsd-hackers@freefall.freebsd.org, ponds!rivers@dg-rtp.dg.com >I can reproduce this easily with kermit - the particular status >of it right now (in reproduction) is (output of /bin/ps -gaxl): > UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND > 0 1647 1459 15 3 0 744 104 ttyin I+ p0 0:00.64 kermit Use pstat to debug tty hangs. >kermit is connected to /dev/cuaa0 - whose tty settings are: >ponds# stty -f /dev/cuaa0 -a >speed 38400 baud; 0 rows; 0 columns; >lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl > -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin > -nokerninfo -extproc >iflags: -istrip -icrnl -inlcr -igncr ixon ixoff -ixany -imaxbel ignbrk > -brkint -inpck ignpar -parmrk >oflags: -opost -onlcr -oxtabs >cflags: cread cs8 -parenb -parodd hupcl clocal -cstopb crtscts -dsrflow > -dtrflow -mdmbuf >... The flow control settings are unusual and bad. Why use both crtscts and ixon/ixoff flow control? ixoff (aka TANDEM) flow control is broken as designed and might cause hangs if the flow control characters are not sent or received properly. There are a couple of races in the driver that might cause the characters to be dropped even when the line is perfect. ixon flow control (ordinary ^S/^Q flow control of output, which is what is needed to honor the other side's using ixoff flow control) works fine (provided the ^S/^Q are received), but is very inefficient. On a 486/33, it costs 50% overhead per line at 115200 bps, limiting you to at most one line at this speed. On a P133, it costs 6% overhead at 115200 bps. > The behaviour I get is that when large amounts of data are generated >at the other end (after dialing a remote system) - I get several >screen-fulls of output, then everything stops.. *However* from the >modem lights, I see that the modem is still receiving data... it's just >not getting to the kermit process to be written out. This probably isn't directly caused by the flow control problems - everything would probably stop if flow control gets stuck off. It might be caused by the extra overheads swamping the machine and hitting bugs in the boundary cases, but the overheads are probably small enough not to matter at a low speed like 38400. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608162334.JAA07420>