MacPPC serial ports in 4.0.1 - not quite

[Donald Lee <MacPPC2%caution.icompute.com@localhost>]

I have some results to report on my migration from my trusty 68K
Mac II ci  (anyone want a Mac IIci cheap?) to a Beige G3 (OFW 2.4).

This is a production machine, and is intended as a system monitor.  It needs
to be able to dial the phone, and therefore needs to be able to do
serial.  The 68K serial was flawless.  The PPC serial has been troubled.

With NetBSD 1.6.2 and 2.1, where I also needed to do incoming PPP
dial-up, I bought a PCI card (Cyclades) and hacked the driver a little
to make it work.  I found in my testing on NetSD 4.0.1, that serial
"just works", so I used the stock kernel (!) and put it in production.

I find lots to be happy about in NetBSD 4.0.x.  The kernel is stable
and the install system works well (with the exception of a bug in
installboot, which always fails - separate mail)

Thank you all for putting this together and your continued diligence.

Now the bad news.

I got my serial port - /dev/tty00 (ttyZ0) - into a bad state last
night that looks suspiciously like one of the problems that
drove me to hack the Cyclades card/driver.  I'm not sure what
got me into this state, so I have not reproduced it.

I could tell from the lights on the modem that the data was going out,
and that the responses were coming in from the modem, but the data never
shows up on reads from the device.  From the host side, it becomes a
"write only" serial line.  The other line - /dev/tty01 - continued
to work.  I swapped cables, modems, and SW to satisfy myself that tty01
was working fine, and tty00 was not.  Incoming data on the serial would
go to a black hole, and never appear.

This is not a serious problem for me, because to operate the modem
in my environment, the return data from the modem is
only a convenience.  Without it, my application still does what it
has to do.

I had been hoping that my experience meant that PPP was now reliable
on MacPPC, but I'm betting we're not there yet.

Oddly enough, when this happened, the "top" display began to show
about 20% user CPU usage, when there was absolutely no excuse for
it that I could find.  I'm theorizing that whatever got confused in
the kernel to "lose" the incoming serial data may also have messed
up the CPU accounting stats.  This may or may not be related.

...just a user reporting in....  I suppose a send_pr would be in order
here.....

-dgl-