Re: Losing Characters Only on Kermit

2000-05-29 Thread Vern Hoxie

On Fri, 26 May 2000, Frank da Cruz wrote:

 So back to the original question: Does anybody have a theory why
 Kermit would lose incoming bytes on a non-flow-controlled
 serial-port connection at 38400 bps (or any other speed), when
 Minicom does not lose them on the same port at the same speed?

It sounds as if the getty is stealing characters.  Minicom relies on
the non-POSIX lock in the kernel.  This is invoked when using
/dev/cua*, it blocks the getty from opening the associated /dev/ttyS*
device.  However, this technique can also invoke the nefarious
"process respawning too often" error message from 'init(1)'.

Kermit does create the external uucp type lockfiles.  This procedure
requires a 'getty' which recognizes this type of lockfile.

See the "locks.blurb" in my "serial_suite.tgz".  This is a collection
of blurbs about the care and feeding of the serial ports and some
simple programs.  There is a file demonstrating how the lock files
should be programmed. There is a simple getty, a dialer for ppp
connections and some other misc programs.

Via ftp:

ftp scicom.alphacdc.com

Login as "anonymous" then use your full e-mail address as the password.
For me, that is '[EMAIL PROTECTED]'.

cd pub/linux

or:

URL ftp://scicom.alphacdc.com/pub/linux

Paul may have to use a smarter 'getty'.  The one in the serial suite
isn't terribly smart but it does demonstrate the use of lockfiles.

vern

-- 
Vernon C. Hoxie [EMAIL PROTECTED]
3975 W. 29th Ave.uucp: 303-455-2670
Denver, Colo., 80212voice: 303-477-1780
 If you ain't makin' waves, you ain't kickin' hard enough!

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]



Re: Losing Characters Only on Kermit

2000-05-26 Thread Frank da Cruz

 Dear Kermit Support:
 
 I'm having a problem with Kermit losing characters on a direct serial
 connection.  I am trying to make a connection to a piece of networking
 equipment that has a serial connection fixed at 38400,8N1, no flow control.
 The port uses TX, RX and Signal GND only.  The networking equipment appears
 to be recieving characters just fine, but I'm only receiving 2-5 characters,
 then missing 1-10+ characters.  I have not been able to identify a pattern
 with the lost characters.
 
 I'm using a PC with RedHat 6.0 with the standard workstation install.  I
 have installed C-Kermit 7.0 from RPMs from RedHat and from Columbia.  I have
 also tried the individual binaries with no success.
 
 I have no problems running minicom (under RedHat 6.0), Kermit (under DOS),
 or HyperTerm (under Win98) on the same computer.  I have also used a 2nd
 computer to verify that things are set up correctly.  I have connected the
 PC running Kermit to the 2nd computer (using HyperTerm) at 38400, 8N1 and
 had no problems.  I connected the 2nd computer (using HyperTerm) to the
 network device and had no problems.
 ...
 Any suggestions?  I've run out of ideas for troubleshooting this problem.  I
 need to get Kermit working becuase I will be using it with Tcl/Expect an a
 larger application.
 
As we discussed on the phone, I'm totally clueless, so I'm forwarding this
message to the Linux-Serial mailing list.

If Minicom does not lose incoming characters when there is no flow control,
I can't imagine why Kermit would lose them.  It can't be explained by any
of the normal phenomena: interrupt conflicts, substandard UART, etc.

My hypothesis was that some other process (e.g. getty/mgetty/...) might be
reading from the same port at the same time, and Minicom does something that
Kermit doesn't do to turn off the getty.

The only other clue I can offer is that Kermit uses select() to multiplex
between the port and keyboard.  I don't know what Minicom does -- maybe it
uses forks and blocking reads like Kermit used to in previous versions.
If you want to test that hypothesis, get the Kermit sources from:

  ftp://kermit.columbia.edu/kermit/archivescku196.tar.gz

Uncompress, untar.  Then:

  mv ckucon.c ckucns.c
  make linux

This gives you a fork/block-read version (./wermit), as in C-Kermit 6.0.  If
this works and the regular C-Kermit 7.0 doesn't, then we know something is
amiss with select() in Linux.  However, there have been no other reports like
yours so I'll be surprised if that's how it turns out.

Does anybody else have any ideas?

- Frank


-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]