efb@suned1.Nswses.Navy.MIL (Everett F Batey) (02/07/91)
Just upgraded our Sun 3/160s from 4.0.3 to SunOS 4.1.1. Did all the readme stuff, cua0, ttyd0, getty (for callers), set all the file permissions and did the make nodes for the cua0,1 (12, 128, ... ). Most of the time, but not all, uucico responds the following messages when we try to call out: mchFind called (tgthost) conn(tgthost) Device Type ACU wanted mlock cua0 succeeded generic open failed, errno = 16 set interface UNIX getto ret -1 Call Failed: CAN'T ACCESS DEVICE exit code 101 Conversation Complete: Status FAILED Suns trouble shooting reminds to see that the speed token (19200 OF Systems file) correlates with Devices, ... and all do so. Trying with cu and tip, get the same failure, all ports busy. This same port and telebit, as then configured are UNCHANGED from when they worked with the other SunOS 4.0.3 on 1 Feb. Notably there are small subtlties in the configs and I would not be surprised if they handled handshaking differently on the system between applications and hardware. Has anyone else met this difficulty CALLING OUT (only) and found a cure or a way to diagnose this one. Thanks for any help. /Ev/ -- + efb@suned1.nswses.Navy.MIL efb@gcpacix.uucp efb@gcpacix.cotdazr.org + + efb@nosc.mil WA6CRE Gold Coast Sun Users Vta-SB-SLO DECUS gnu + + Opinions, MINE, NOT Uncle Sam_s | b-news postmaster xntp dns WAFFLE +
guy@auspex.auspex.com (Guy Harris) (02/08/91)
>generic open failed, errno = 16
When I find the person who first invented the idea of printing "errno"
as a decimal number and *not* as an error string, I'm going to give him
or her the old Hot Lead Enema....
16 is EBUSY, so apparently the system thinks the "cua0" port is busy.
One reason why the dialout side of a dialin/dialout device might be busy
is that it really *is* busy, i.e., the dialin device has been opened
successfully. I presume there's nobody dialed in on that port at the
times this failed (otherwise you wouldn't have found it surprising that
it couldn't call out). Make sure that the line in "/etc/ttytab" for
"ttyd0" and "ttyd1" does *NOT* have "local" in it; if it does, remove
the "local", and run "ttysoftcar -a", to turn off "soft carrier".
In any case, next time it tries to dial out and fails, try "ps -td0"
if the device was "cua0", or "ps -td1" if it was "cua1". If "ps" reports
that there was a process attached to "ttyd0" or "ttyd1" (whichever is
the dialin half of the dialout device that it couldn't use), that's the
problem - the device really *is* busy. The next step is to track down
why it's busy (I suspect it's not something obvious like the modem or
the cable pulling CD permanently up, as that would cause the same
problem under 4.0.3).