Trivial check: Did you set the CRTSCTS flag in the c_cflag parameter to tcsetattr() in your linux application code ? Or in the corresponding ioctl(..., TCSETA,...) call ? > -----Original Message----- > From: linux-serial-owner@xxxxxxxxxxxxxxx > [mailto:linux-serial-owner@xxxxxxxxxxxxxxx]On Behalf Of Lee Howard > Sent: Thursday, July 26, 2007 3:53 AM > To: linux-serial@xxxxxxxxxxxxxxx; tytso@xxxxxxx; rmk@xxxxxxxxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx > Subject: serial flow control appears broken > > > Hello. > > I have fax modems that will, in their proper behavior with certain > features, send up to 64 kilobytes of data to the host DTE all > at once. > (So, the fax modem handles an incoming fax and periodically will send > between 256 bytes and 64 kilobytes of data in bursts.) > > When the DCE-DTE (modem-to-host) communication rate is established at > 115200 bps data loss occurs systems using at least Linux > kernels 2.6.5 > and 2.6.18 (and probably everything in-beween and then some > more). This > is because the modem overflows the host's buffer. This is > evidenced in > kernel logging: > > Jul 23 14:01:30 gollum kernel: ttyS1: 1 input overrun(s) > Jul 23 17:09:45 gollum kernel: ttyS1: 1 input overrun(s) > > Normally I would blame the modem itself for not honoring the > host's flow > control signals. However, I have worked with the modem manufacturer > closely on this matter for over three months now. In that > process they > have improved the responsiveness of the modem and have fixed other > problems, but the end result is that it truly does appear that the > serial tty driver is not using flow control. Whether software flow > control (XON/XOFF) or hardware flow control (RTS/CTS) is used > the result > is the same. > > This is evidenced in hardware flow control by a little LED > labeled "RTS" > that is on the external modem. This LED lights up when pin 7 > of the DB9 > serial connection is given +12Vdc current (signalling "RTS" > is on - that > the host can accept data). The LED goes dark when the current is > removed (signalling that the host cannot accept data). This > "RTS" LED > never flickers at all, as it should, when receiving these > bursts of data > - the LED stays lit as long as the serial cable is connected to the > host... and yet I will see those "input overrun" messages. Thus, it > seems quite clear that the Linux serial tty driver is not deasserting > RTS as it should in hardware flow control. (And probably the > analogous > problem exists in software flow control, too.) > > Please tell me what I can do to help you resove and/or remedy this > matter. Also, please let me know if I have contacted the > wrong people. > (I have cross-posted to linux-kernel as a catch-all. I am not > subscribed to either linux-serial or linux-kernel mailing lists. So > please CC me in any list responses.) > > If it is of any value to know (perhaps they have common > code?), the same > error occurs on FreeBSD 6.2 as well. The problem does not occur on > Windows. The problem does not occur on RedHat 6.0 (kernel 2.2.5). > > Thanks, > > Lee. > > - > To unsubscribe from this list: send the line "unsubscribe > linux-serial" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
