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/