Date: Sat, 13 May 1995 19:14:31 +1000 From: Bruce Evans <bde@zeta.org.au> To: freebsd-current@FreeBSD.org, terry@cs.weber.edu, uhclem%nemesis@fw.ast.com Subject: Re: Taylor UUCP Message-ID: <199505130914.TAA22035@godzilla.zeta.org.au>
index | next in thread | raw e-mail
>[1]This is because most systems don't handle CTS/RTS correctly prior to DCD
>[1]being raised on outgoing calls, and act wierd if DCD is lost while CTS
>[1]or RTS has been deasserted.
>Whatever. I was more concerned with the data part of the call, which
>is the point when Taylor turns this off. Nearly all of the other
>System V systems I have seen leave RTS/CTS active if you wanted it on.
>Even SCO.
Actually it seems to turn crtscts on for the sender and off for the receiver,
at least when the receiver is spawned by getty. You are supposed to be
able to specify the flow control in the `port' file (hardflow y) but it
defaults to on anyway. I think the problem is that uucico doesn't know the
port when it is spawned by getty, and the port info doesn't get initialized
right.
Other bugs:
1) You are supposed to be able to check and convert configurations using
uuchk and uuconv, but these are installed in the wrong place
/usr/libexec/uucp with the wrong ownership uucp:uucp and the wrong
permissions 550.
2) If /usr is nfs-mounted and root attempts to run /usr/libexec/uuchk,
then the following error is logged:
vnode_pager_input: I/O read error
vm_fault: pager input (probably hardware) error, PID 212 failure
Apparently FreeBSD still has the nfs bug that root can open nfs-mounted
files that can't be read (the file permissions lie), and the vm system
is as confused about this as everything else.
Bruce
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505130914.TAA22035>