DragonFly users List (threaded) for 2006-10
Re: silo overflows -- what can I do about this?
:Joseph Garcia wrote:
: > It connects and I can log in and enter commands. The problem pops up
: > when receiving a lot of data quickly from the device (i.e. when I'm
: > writing the configuration to the terminal).
:Maybe I'm completely missing the point here, but your
:description sounds like it could be a problem with
:flow control or handshaking. Dit you try to enable
:it on your serial port? stty(1) has several options
:for that (note that you must apply them to the lock-
:state device or initial-state device, otherwise they
:might be reset on the next open of the actual device;
:see sio(4) for details).
:Just an idea. Sorry if the problem is somewhere else.
Probably wouldn't be a good idea to program a cisco to use
hardware flow control on the console port. I have a cisco
too and telnet is basically the way to go. You just set up the
firewall rules to only allow connections from a single internal host.
Cisco's can also talk TFTP. So, e.g. with my little cisco
! copy tftp://blah.blah.blah.blah/some/path/filename running-config
! Primary incoming filter for T1
[ config commands ]
And I just cut-and-pate the copy line into the cisco and it pulls the
config via TFTP.
The 16550A can't do hardware flow control (CTS/RTS based flow
control) in hardware, it's actually done by the interrupt handler
in the driver. Well, that is, the 16550A *has* a hardware flow
control mode, but it was implemented incorrectly 25 years ago
and it has never been fixed, ever. Nobody uses it because of that.
Serial ports are being used less and less. I use a modem
only very occassionally these days. I haven't had any problem
running PPP over the modem at 19200 but I know for a fact that there
*ARE* interrupt latency issues in DragonFly that have not been
addressed that could well be responsible for lost characters on a
tty. While I want to fix the latency issues, it's near dead last
on my list of important things to do.
I someone else wants to investigate the latency issues DragonFly does
have a utility called pctrack (man pctrack) which works with kernels
compiled with DEBUG_PCTRACK. This utility is a very low level utility
and would be difficult to use by a non-programmer, and even then it
would be difficult to use. It tries to record the PC as of when
a statistics clock interrupt occurs. The idea is that areas of
code which entail very long interrupt latencies will record the PC
as of the crit_exit() that finally allowed interrupts to be processed
again. Unfortunately it doesn't work as well as I would like and
more often then not the PC's recorded are not useful in helping track
down latency issues.