Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.edu!know!cs.utexas.edu!helios!andrewd
From: andrewd@cs.tamu.edu (Andrew Ted Duchowski)
Newsgroups: comp.sys.next
Subject: Re: /dev/cua busy cont.
Summary: more problems
Message-ID: <14329@helios.TAMU.EDU>
Date: 8 Apr 91 08:18:43 GMT
Sender: usenet@helios.TAMU.EDU
Followup-To: andrewd@cs.tamu.edu,comp.sys.next
Distribution: usa
Organization: Computer Science Department, Texas A&M University
Lines: 65


Hi, 

some time ago I posted a problem with /dev/cua getting locked
("device busy").  Thanks to all those who replied.
Because some people mailed me that they were experiencing
similar problems, I'm posting somewhat of a progress report.

First of all, I hadn't configured my modem, so that was
part of the problem.  I used
  AT &c1 &d2 s0=6 &w0
to set up DTR and DCD correctly (s0=6 is just for number
of rings before answering) and &w0 writes to non-volatile
memory.  Basically all this helped fix was the problem
of the modem not hanging up when I exitted kermit.
This did not help with /dev/cua being busy.

I found that I could use /dev/cua in single user mode
but not in multi-user.  With further experimenting, I
am now logged on at school thru the modem, writing this message.
It turns out that if I had the getty sitting on /dev/ttyda,
I couldn't get hold of /dev/cua.  It seems to me that
ttyda (dial in) cua (dial out) were originally designed
to somehow share the serial port (A in this case), however
ttyda seems to hold on to the port so that cua couldn't
grab a hold of it.  Some say this is a 2.0 bug and I 
should get 2.1 (btw, where can I get 2.1?).  So effectively
what I had to do was to turn off the getty on ttyda.
(Edit the /etc/ttys file, and set the on/off field to
off; kill -HUP 1).  I guess basically what this does is keeps the
port free, enabling kermit (what I'm using now) to get
a hold of cua whenever I start it up.

Now, although I can dial out, for some reason I can't
escape back to my local kermit.  I'm using 4E, so
perhaps there's a problem there.  I'm working on getting
kermit 5A...  Is this because of the getty not being there?
I have to kill -9 kermit now.  I suppose it's better than
not being able to dial out at all (or at least better
than from single user mode).

What a joke.  Is there a *clean* way to iron these problems
out?

Btw, I just saw a post about the same problem.  The person
said that tip and kermit don't work on /dev/cua, but rather
on /dev/cub.  I don't believe it's a "port A vs port B" 
problem.  I'm using /dev/cua right now.  One thing that
does help is being root.  Even though my permissions appear
to be set up "right", ie. as the consensus dictates (/dev/cua
owned by uucp, kermit owned by uucp w/sticky bit set).
Even though kermit has the sticky bit, it still complains
about not being having permissions on lock files.  This
seems to be a pre-5A problem, so I can overlook it untill
I get 5A I suppose.  As far as the recent reply about this
problem and LCK..cua file, kermit ought to tell you about
it.  My 4E version does.

Thanks in advance for any further help/suggestions,
Andrew
andrewd@cs.tamu.edu

--

-------------- Not an Official Texas A&M University Document --------------