csg@pyramid.UUCP (Carl S. Gutekunst) (09/13/85)
I encountered a bizarre problem with UUCP recently on which I'd appreciate
comments from UUCP wizards.
The situation: machine pyramid (a Pyramid 90x) polling a customer's system
under 4.2bsd, via their Gandalf port selector. Both ends use Hayes 1200
Smartmodems. It was necessary to go through a dialog with the Gandalf, then
send a BREAK to the Pyramid to make getty step to 1200 baud (they chose to
default to 2400). The L.sys entry was:
customer Any ACU 1200 555-5555 "" \d\r class-\d\r-class \dp1 \
start "\b\c" ogin:--ogin:--ogin: Upyramid assword: passwd
In brief, our system sent a break immediately after seeing "start", and then
expected to see a login: prompt at 1200 baud.
But instead, the remote Pyramid almost always got TWO breaks, causing it to
step back around to 2400. I had never seen this happen before on any system,
including on other Pyramids.
The 4.2 UUCP break generation code in conn.c (stripped for readability) is:
genbrk(fn, bnulls)
int fn, bnulls;
{
ioctl(fn, TIOCSBRK, NULL);
write(fn, "\0\0\0\0\0\0\0\0\0\0\0\0", bnulls);
sleep(1);
ioctl(fn, TIOCCBRK, NULL);
}
where _bnulls_ is user supplied in L.sys and defaults to 3. Figuring that a
write followed by a sleep was redundant, I commented out the sleep. And it
worked perfectly. Commenting out the write also worked, but not as well. Note
that on a Pyramid the ioctl is synchronized to the write, so a 3-character-
length break occurs, regardless of the baud.
Has anyone else ever encountered this? Is one or two seconds too long for a
break? (Remember that sleep(1) can last as long as two seconds.) I think of
Ye Goode Olde Days on an HP2000 when a two-second break caused a hangup. Is
the break ioctl synchronous with regular I/O on other systems?
BTW, 4.3bsd UUCP and tip both use only a 1-second sleep between the ioctl
calls. V.2.2 UUCP sends a single null character at 150 baud, followed by an
'@' at the normal baud.
--
-m------- Carl S. Gutekunst, Software R&D, Pyramid Technology Corp.
---mmm----- P.O. Box 7925 {allegra,decwrl,dual,nsc,sun}\
-----mmmmm--- Mt. View, CA {ihnp4,uiucuxa,uwvax}!pyrchi >!pyramid!csg
-------mmmmmmm- 415/965-7200 topaz!pyrnj/guy@sun.uucp (Guy Harris) (09/14/85)
The original V7 code for transmitting breaks did so by setting the speed to some strange value and writing a pile of NULs. This was because the V7 TTY driver didn't give you access to the break-generation hardware that was in the PDP-11s (and lots of other machines') terminal muxes. The S3, S5R1, and S5R2 code just does a TCSBRK system call which turns on the mux's break bit for 1/4 sec and then turns it off again. S5R2V2 may do it differently (I don't have the source handy). 4.1BSD and 4.2BSD have no call to send a timed break; they just have the ability to turn the break bit on and off. I suspect the code for the 4.2BSD UUCP may be a mix of the V7 code and code that used TIOC[SG]BRK. The way it's written there may be a historical dreg. OK, Peter, what does honey danber do? Guy Harris
honey@down.FUN (Peter Honeyman) (09/16/85)
in system v it uses TCSBRK. in v8 it uses TIOCSBRK (like system v -- no TIOCCBRK). otherwise, it uses TIOCSBRK, nap(1/3 sec.), TIOCCBRK. peter
sob@neuro1.UUCP (Stan Barber) (09/19/85)
I thought it only used the nulls if the regular ioctls (TIOC*BRK on
4.2 and TCSBRK on SYSV) failed. I know in some versions of
some device drivers, the ioctls don't work and don't return the error
[that is, the hardward device is not capable of sending a hardware
break and the device driver writer did not bother to implement
anything to overcome this problem or return and error.]; does
your uucp not have these options in the genbrk subroutine?
--
Stan uucp:{ihnp4!shell,rice}!neuro1!sob Opinions expressed
Olan ARPA:sob@rice.arpa here are ONLY mine &
Barber CIS:71565,623 BBS:(713)660-9262 noone else's.