msc@qubix.UUCP (Mark Callow) (06/20/84)
This is a followup to my article of about 2 weeks ago referring to
a bug in the 4.2 uucp dialer software that causes all subsequent
dialups to fail in a single invocation of uucico if the first
dialup fails.
I have received messages from several people who have also
seen this problem. Thank you for those messages.
I have done some further investigation. The immediate cause of the
failure (as I mentioned) is that the system returns EIO when
uucico is trying to read the result byte from the dialer to find
out if it worked. I have put 2 printf's in the kernel and have found
that the EIO is returned from the following piece of ttread code
and not from the test on carrier that Bill Sebok suspected.
================================================
/*
* Hang process if it's in the background.
*/
#define bit(a) (1<<(a-1))
while (tp == u.u_ttyp && u.u_procp->p_pgrp != tp->t_pgrp) {
if ((u.u_procp->p_sigignore & bit(SIGTTIN)) ||
(u.u_procp->p_sigmask & bit(SIGTTIN)) ||
/*
(u.u_procp->p_flag&SDETACH) ||
*/
u.u_procp->p_flag&SVFORK) {
*************** return (EIO);
}
gsignal(u.u_procp->p_pgrp, SIGTTIN);
sleep((caddr_t)&lbolt, TTIPRI);
}
=====================================================
The line marked with *'s is the where the EIO is coming from.
Anyone have any idea what's going on? The first question which arises
is how does the dialer become the controlling tty of the uucico process?
--
From the TARDIS of Mark Callow
msc@qubix.UUCP, decwrl!qubix!msc@Berkeley.ARPA
...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!msc
"Nothing shocks me. I'm an Engineer."