From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Subject: Re: serial driver fixes for 0.98pl5 Date: Sat, 28 Nov 1992 17:53:33 GMT
From: Jim.Corbett@f35.n152.z1.fidonet.org (Jim Corbett)
Date: Sat, 28 Nov 1992 01:56:00 -0800
1) I have three serial ports, dos COM1-int4, COM2-int3,
and a COM4 w/o any interupt assigned to it.
If a serial port has no interrupt assigned to it, Linux will not be able
to use it; this is why when AUTO_IRQ is defined, it does not configure
/dev/ttys3, because you wouldn't be able to use it anyway.
2) I have a AST-FOUR PORT card, but it is in a metal cabinate on the
other end of the house. You write very good code for it to be able to
detect the card that does not even have power conected to it!
Um, no. What are you talking about? The bootup message said anothing
about detecting the AST-Fourport cards. If it did, it would have
configured ports in the range /dev/ttys4 through /dev/ttys11.
If you're talking about the first line on the boot screen:
Serial driver version 3.0: AST_FOURPORT AUTO_IRQ NEW_INTERRUPT_ROUTINE
This merely identifies why #ifdef's the serial code was compiled with.
I added this because I've found you can't always trust people to be able
to accurately tell you how they compiled the kernel, and the serial
driver had enough #ifdef options that it could get confusing. The
AST_FOURPORT just means that the serial driver has been compiled with
support for the Four-port card, not that it actually detected such a
board. Fourport support does not require much extra code, and as far as
I know it doesn't interfere with any other boards, so I left it on by
default. In contrast, support for the Accent Async board would
interfere with people with SCSI adaptors, so it's off by default.
3) No problems noted using the second serial port (tty1)
using Kermit @34.8 baud to connect to a MSDOS PC runing
kermit in server mode.
that's good.
4) I do have a problem with flow control using Kermit, it
is only present when NWLite is running on the MSDOS PC and
kermit is running. The problem is kermit on Linux gets two
or three NAKs each time it writes to the drive when
GET filename is used to get a file from the MSDOS PC.
If NWLite is not loaded and running on the MSDOS PC, then I
can multitask on the Linux system without any NAKs.
My guess it that Xon/Off is getting ignored by the MSDOS PC
when NWLite is loaded.
Either that, or NWLite is disabling the hardware flow control on the PC.
PS, I would like to know what files in the linux source I need to patch
to allow me to patch KERMIT so I can get 57.6 and or 115.2 (my MSDOS
kermit is limited to 115.2 as I believe that is as fast as the uarts
will run with the clocks they have hooked to them).
What you need to do is write a small program which does something
roughly like this
ioctl(fd, TIOCGSERIAL, &sstruct);
sstruct.fflag &= ASYNC_SPD_MASK;
#ifdef WANT_56KB
sstruct.fflag |= ASYNC_SPD_HI; /* Use 56000 instead of 38400 */
#else
sstruct.fflag |= ASYNC_SPD_VHI; /* Use 115200 instead of 38400 */
#endif
ioctl(fd, TIOCSSERIAL, &sstruct);
.... where fd is a file descriptor which is open on the serial port; and
of course, you'll need to do error checking, which has been omitted in
this code fragment. Also note that the Linux kernel as currently
configured uses 56000 bps for ASYNC_SPD_HI, instead of 56700, because
that's what's in the National Semiconduct Spec. The rest of the world
seems to use 56700, so if you want, you can make that change in
baud_table[] in serial.c. It actually doesn't matter, since whether you
use 56000 or 56700, you get the same baud rate divisor, which is what's
important anyway.
After you run this program, the serial port will be sent so that when
38400 is selected, the actual speed of the port will really be 56000 or
115200. So all you need to do is tell kermit "set speed 38400";
depending on what kermit you are using, you may need to recompile it and
possibly modify it to force it to include support for the 38400 speed.
- Ted