Messages in this thread | | | From | Dean Salvadore <> | Date | Sun, 29 Aug 1999 16:10:27 (PDT) | Subject | Serial protocol bug in the 2.1.x through 2.2.12 kernels |
| |
Hello,
I believe I have discovered a bug in something that effects transfers of data over a serial line (not on a modem). The problem is that the above kernels somehow break kermit, xmodem, zmodem etc., transfers over a direct connection. I discovered this when I tried to use kermit to talk to my HP 48Gx calculator and my Palm Pilot IIIx. Both of these devices can be communicated with using the same cables on my Solaris box.
I compiled a 2.0.X kernel and the serial devices all worked fine. This is why I believe that the 2.1.x and 2.2.x kernels break some part of the serial communications. Here is a post that illustrates the problem and a possible cause for such; --------------------------------------------------------------------------- Hi All! ;-)
We are attemping to port an application from SCO to Linux Redhat 6.0. This is a gaming application that uses a radio modem to communicate with the various guns, scoreboards, etc. that are used in the game. Although everything seems to work fine under SCO, we are having a great deal of trouble under Linux. Although we can reliably write messages to the hardware, we can only receive them sporadically. This seems to be a problem related to flow control. (Oddly the output seems to work fine with hardware flowcontrol, but flow control must be disabled to receive data from the guns, etc., in Linux.) Again this all works quite well under SCO. Our best results are obtained by turning on the flow control flags BEFORE writing :
nResult = ioctl ( nFD , TIOCMGET , & nSet ) ;
debugLnF ( "ioctl returned:\t" << nResult ) ;
nSet |= TIOCM_RTS ; nSet |= TIOCM_CTS ; nSet |= TIOCM_DSR ; nSet |= TIOCM_DTR ;
nResult = ioctl ( nFD , TIOCMSET , & nSet ) ;
tcdrain ( nFD ) ;
tsp.tv_sec = 0 ; tsp.tv_nsec = 15000000 ; nanosleep ( & tsp , & tsr ) ;
nResult = write ( nFD , pcucBuffer , uBuffLen ) ;
and turning them OFF before reading :
tsp.tv_sec = 0 ; tsp.tv_nsec = 15000000 ; nanosleep ( & tsp , & tsr ) ;
ioctl ( nFD , TIOCMGET , & nSet ) ; nSet &= ~TIOCM_RTS ; nSet &= ~TIOCM_CTS ; ioctl ( nFD , TIOCMSET , & nSet ) ;
nResult = read ( nFD , pucBuffer , uBuffLen ) ;
I am not sure why it is necessary to sleep BEFORE calling ioctl when reading and AFTER calling IOCTL when writing, but experimentation has shown this to be the best setting for Linux. Again NONE of this monkeying around with ioctl and nanosleep is necessary when using SCO, and we initialise the termios flags identically within SCO and Linux. Is anyone familiar enough with the serial port settings under SCO or Linux to tell us what could possibly be the matter, i.e. what SCO does to initialise a serial port that is different than what Linux does? Lastly we are INITIALLY setting the termios flags as : octl (filedes, TCGETA, &Term); /* read parameters */ Term.c_lflag &= ~(ECHO | ICANON | IEXTEN | ISIG); /* echo off, canonical mode off ** extended input processing off, ** signal chars off */ Term.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON ); /* no SIGINT on BREAK, CR-to-NL off, input ** parity check off, don't strip 8th bit ** on input, output flow control off */ Term.c_cflag &= ~(CSIZE | PARENB); /*zero out the bits, parity check off */ Term.c_cflag |= CS8; /*set 8 bits/byte*/ Term.c_cflag &= ~CLOCAL; /* RTS & CTS asserted.*/ Term.c_cflag |= CRTSCTS; /* set hardware flow control */ Term.c_cflag |= CREAD; Term.c_cflag |= B9600; Term.c_oflag &= ~(OPOST); /*output processing off*/ Term.c_cc[VMIN] = 0; /* bytes minimum */ Term.c_cc[VTIME] = 0; /* time to wait after the first char*/ ioctl (filedes, TCSETA, &Term);
I am sorry for the long message, but we are at our wits end with this, and it is REALLY important that we get this software running correctly under Linux to demonstrate the viability of the platform. (Our CIO is willing to convert the whole shop to Linux, but we need to deliver this first!)
Thank you VERY much
Peter -----------------------------------------------------------------------------
Well, I hope that helps you find the problem or at least a workaround. Thanks,
-- "You don't have to wait for good things to happen... "You are a good thing that is happening!" Dean salvadore deansalv@home.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |