Mailing List Archive

Date: Fri, 22 Jan 1999 10:12:57 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
Using version 2.1.131, I cannot set the baud rate of a terminal
to a speed higher than 38400 baud without cheating and using the
`setserial spd_hi` function. This function now results in a
warning message that it has been deprecated.
>From termbits.h
#define B38400 0000017 Works and everything below.
#define B57600 0010001 Sets baud-rate to about 600 baud
#define B115200 0010002 Sets baud-rate to about 1240 baud
#define B230400 0010003 Sets baud-rate to about 800 baud
#define B460800 0010004 Sets baud-rate to about 900 baud
Is this a bug or have I forgotten to set some magic high-speed
bit?
What version of libc do you have on your machine, and what application
and what version are you using to set the speed? Furthermore, how are
you measuring the speed?
I just timed the amount of time it took to send a largish file out the
serial port, which was configured with flow-control off, and which had
nothing attached to it. (i.e., "time cat large-file > /dev/ttyS0").
When I increased the speed from 38400 to 57600, the time it took to
transmit the file dropped in half. When I further increased the speed
to 115200 bps, the time to transmit the file dropped in half again.
If you are getting the higher speeds using setserial spd_hi, but it's
not working via directly setting the baud rate, my guess is that you
have an out-of-date libc, which doesn't know about speeds faster than
38400; that must be a *really* ancient libc though, which is rather
curious. Kernel support for 57600 and 115200 have been around since at
least the 2.0 kernel, and possibly even the 1.2 kernel. There hasn't
been real need to use setserial spd_hi for years, assuming an up-to-date
libc.
- Ted
-
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/

On Fri, 22 Jan 1999, Theodore Y. Ts'o wrote:
> Date: Fri, 22 Jan 1999 10:12:57 -0500 (EST)
> From: "Richard B. Johnson" <root@chaos.analogic.com>
>
> Using version 2.1.131, I cannot set the baud rate of a terminal
> to a speed higher than 38400 baud without cheating and using the
> `setserial spd_hi` function. This function now results in a
> warning message that it has been deprecated.
[SNIPPED termbits.h]
> What version of libc do you have on your machine, and what application
> and what version are you using to set the speed? Furthermore, how are
> you measuring the speed?
I am using a fairly recent version of glibc. I'm directly making
an ioctl(TCSETS, &struct_termios) with the above shown parameters
set.
There are no errors. A connected modem works fine. However, this
is a long-used call-back program which runs fine at speeds at and
below 38400. However when I set the speed to higher values, I noted
that the modem would only connect at 1200 baud!
Therefore I got out my scope and timed it. (cat /dev/zero /dev/modem).
I measured the time between start-bits (zeros are only start-bits).
Assuming 10-bits/baud (1 stop, 1 start, and 8 data), the speeds are
as shown. Everything works fine if I use 38400 and set the SPD flag
with setserial.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.131 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.
-
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/

On Fri, 22 Jan 1999, Richard B. Johnson wrote:
> On Fri, 22 Jan 1999, Theodore Y. Ts'o wrote:
[SNIPPED]
>
> I am using a fairly recent version of glibc. I'm directly making
> an ioctl(TCSETS, &struct_termios) with the above shown parameters
> set.
>
> There are no errors. A connected modem works fine. However, this
> is a long-used call-back program which runs fine at speeds at and
> below 38400. However when I set the speed to higher values, I noted
> that the modem would only connect at 1200 baud!
>
> Therefore I got out my scope and timed it. (cat /dev/zero /dev/modem).
> I measured the time between start-bits (zeros are only start-bits).
> Assuming 10-bits/baud (1 stop, 1 start, and 8 data), the speeds are
> as shown. Everything works fine if I use 38400 and set the SPD flag
> with setserial.
I found the problem, but I don't know how it happends. Your ioctl()
works fine if I make a simple 10-line program to set the speed.
The problem is that after a fork(), the termios structure somehow
gets modified. I don't know how because the structure is never used
again by the parent. In fact, if I move it off the stack, out of
local data, into global, everything works fine.
This is weird because everything works fine anywhere if the speed is
38400 or less. There are also no local variables larger than an `int`
(no string buffers or longs) that could be overwriting the termios
structure on the stack.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.131 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.
-
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/

Date: Fri, 22 Jan 1999 20:01:08 -0500 (EST)
From: "Richard B. Johnson" <root@chaos.analogic.com>
There are no errors. A connected modem works fine. However, this
is a long-used call-back program which runs fine at speeds at and
below 38400. However when I set the speed to higher values, I noted
that the modem would only connect at 1200 baud!
Well, I can't duplicate it on my 2.2.0-pre7 machine, with RedHat 5.2,
and glibc 2.0.7. What do you get when you try the following procedure?
- Ted
<tytso@rsts-11.mit.edu> {/usr/rtmp}
1027% stty 38400 < /dev/ttyS0
<tytso@rsts-11.mit.edu> {/usr/rtmp}
1028% time cat /sbin/e2fsck > /dev/ttyS0
0.00user 0.02system 1:11.72elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (142major+11minor)pagefaults 0swaps
<tytso@rsts-11.mit.edu> {/usr/rtmp}
1029% cat foo.c
#include <unistd.h>
#include <termios.h>
#include <stdlib.h>
#include <ioctls.h>
main()
{
struct termios io_mod;

memset(&io_mod, 0x00, sizeof(io_mod));
io_mod.c_cflag = B57600|CS8|CREAD|CLOCAL;
io_mod.c_iflag = IGNBRK|IGNPAR;
io_mod.c_cc[VMIN] = (cc_t) 1;
io_mod.c_cc[VTIME] = (cc_t) 1;
if (ioctl(0, TCSETS, &io_mod) < 0)
perror("ioctl");
}
<tytso@rsts-11.mit.edu> {/usr/rtmp}
1030% cc -o /tmp/foo foo.c
<tytso@rsts-11.mit.edu> {/usr/rtmp}
1031% ./foo < /dev/ttyS0
<tytso@rsts-11.mit.edu> {/usr/rtmp}
1032% stty < /dev/ttyS0
speed 57600 baud; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>;
start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>;
werase = <undef>; lnext = <undef>; flush = <undef>; min = 1; time = 1;
ignbrk -brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
<tytso@rsts-11.mit.edu> {/usr/rtmp}
1033% time cat /sbin/e2fsck > /dev/ttyS0
0.01user 0.02system 0:47.79elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (74major+11minor)pagefaults 0swaps
<tytso@rsts-11.mit.edu> {/usr/rtmp}
1034% stty 115200 < /dev/ttyS0
<tytso@rsts-11.mit.edu> {/usr/rtmp}
0.01user 0.01system 0:23.90elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (74major+11minor)pagefaults 0swaps
-
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/

On Fri, 22 Jan 1999, Michael Elizabeth Chastain wrote:
> Jon M. Taylor writes:
>
> > I do not think that blindly adhering to an obsolete design until
> > the last scrap of performance has been wrung from it when a clearly
> > superior alternative is available and free is a very wise use of
> > programmer resources.
>
> Good for you. So Jon M. Taylor, and everyone whose paycheck bears
> his signature, will soon be working on more free software. Cool.
> I wish you well.
No need to be snide. Although this would be true i I could afford
to fund OSS development.

> Does your non-Linux project have its own mailing list yet? Because
> your advocacy is getting in the way of my blind adherence.
If you mean Flux, it is at:
http://www.cs.utah.edu/projects/flux
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
-
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/