Alan Cox wrote:
The manufacturer is using a scope to look for RTS and they're not seeing
it, either. I just use my eyes to look at the LED, but I can see the
CTS, DTR, DCD, RD, and TD lights blink, flicker, or dim... (and TD, RD,
and CTS tend to go on and off rather quickly).
And you have
1. The port set up correctly for flow control options in the
kernel ?
I suppose that you mean that the application has properly set up the
port using termios/tcsetattr/ioctl and the like... rather than if the
kernel build/config options were set to permit flow control (I know of
no relevant flow-control-enabling kernel build options). Using hardware
flow control this is what stty tells me about the port set up done by
the application:
# stty -F /dev/ttyS1 -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase =
^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
#
Using software flow control this is what stty tells me about the port
set up done by the application:
# stty -F /dev/ttyS1 -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase =
^W; lnext = ^V; flush = ^O;
min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon
ixoff -iuclc -ixany -imaxbel
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
#
They seem correct to me, but I am certainly willing to be wrong.
2. Verified that the board vendor remembered to wire it ?
I don't know how to verify directly that the board manufacturer wired
the serial port correctly. I've tested this on two different
motherboards made several years apart (but, yes, both were made by the
same manufacturer). However, when using RedHat 6.0 (kernel 2.2.5) I
have no problems with data corruption occurring in the data coming from
the DCE. So that tells me that *something* was working before that
isn't working now... and I'm trying to determine what the difference
is... whether it be a problem in modern kernels or whether it be
something that the application (HylaFAX) is not doing to accomodate
whatever changes occurred in modern kernels.
A quick google on "input overrun(s)" may lend some credence (although,
certainly this is not in any way conclusive) that I'm not the only one
who may be seeking a solution on this matter.
http://www.google.com/search?hl=en&q=%2B%22input+overrun%28s%29%22
Thanks,
Lee.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
