Uwe Kleine-König wrote:
Hello,
This is evidenced in hardware flow control by a little LED labeled "RTS"
that is on the external modem. This LED lights up when pin 7 of the DB9
serial connection is given +12Vdc current (signalling "RTS" is on - that
the host can accept data). The LED goes dark when the current is
removed (signalling that the host cannot accept data). This "RTS" LED
never flickers at all, as it should, when receiving these bursts of data
- the LED stays lit as long as the serial cable is connected to the
host... and yet I will see those "input overrun" messages. Thus, it
seems quite clear that the Linux serial tty driver is not deasserting
RTS as it should in hardware flow control. (And probably the analogous
problem exists in software flow control, too.)
I don't know the relevant timings for problem, but just to be sure that
your prerequisites are correct: How did you check that the LED stays
lit all the time? Just from looking might not be accurate. You might
want to mesure the signal with an oscilloscope.
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).
All of that said... even though I don't see RTS flicker or blink or dim
when using kernel 2.2.5 (RedHat 6.0) I don't have any problems using
115200 bps DTE-DCE communication rate.
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]
