At 8:23 AM -0500 6/14/00, Donald Lee wrote:
>Howdy,
>
>Recently I've been trying to get the serial ports on my MacPPC and
>Mac68K machines working with NetBSD 1.4.2.  At first I thought the
>problem was that the MacPPC port had some troubles.  ...No serial ports
>on the newer macs, so not much interest or support.  Logical.
>
>I finally tried to get the serial on a Quadra 800 running last night
>though, and find that the serial ports don't seem to work there either.
>
>Symptoms on NetBSD 1.4.2:
>
>	MacPPC: Very strange behavior.  flow control is messed up,
>	erratic behavior otherwise.  I can *sometimes* get a few
>	characters across the wire, but usually not.  I often
>	end up with processes that are trying to talk to serial
>	getting "stuck" while trying to exit().  If I were forced to
>	guess, I'd say the control structure for the ports is
>	filled with garbage so it's confused.
>
>	Mac68K: when I boot, and run std "getty std.57600", things
>	are cool.  If I try to run pppd on the port though, it
>	ends up in a state where the machine will *not* output
>	anything to the serial line.  When I switch it back to
>	running a "getty std.57600" I can log in, and everything is
>	fine *except* that I cannot get any character echo at all.
>	it's like the input side works fine and the output is
>	just dead.
>
>I've not looked at 1.4 and 1.4.1 yet.
>
>Anyone have direct experience with this?  If this is news, I'll
>investigate further.

I've been running 1.4.2 macppc intermittently on a upgraded 7600, and
trying to get it to talk to a GPS.  I discovered that arch/macppc/dev/zs.c
and arch/macppc/dev/ z8530tty.c didn't have the PPS support, and added that
by comparing the various port-specific versions of the file.  I did notice
a typo in arch/mac68k/dev/zs.c (because I copied it into the macppc version):
line 741 (in zs_set_modes) tests to see if DCD is available for PPS input,
	if ((cflag & (CLOCAL & MDMBUF)) == CLOCAL) {
which should be
	if ((cflag & (CLOCAL | MDMBUF)) == CLOCAL) {
Without the change, cs_rr0_pps never gets set non-zero, preventing PPS
timing from being allowed on the interface.

(I also found that the serial cables I have don't carry DCD; the
"handshake in" and "handshake out" pins are not connected at all, and
DTR and RTS are always on; if you're enabling hardware flow control,
this may be a problem.  I was able to receive the PPS signal via
CTS, though, with some more driver changes. )

With the first serial port acting as the console (at 38400), I've seen
it hang occasionally, but I thought that was due to my changes rather
than anything in 1.4.2; I didn't check to see whether it was hanging in
only one direction.  I haven't seen any failures on the second serial
port, which I am running at 9600.

Charles