Hello all,

I want to post a status on my efforts to get my MacPPC NetBSD boxes to
support multiple serial ports, so I can do multiple PPP dial-in modems.

Internal serial ports: still busted.  I can't get them to work.

Cyclades 8Y card: good news.  I have it working - with the
caveats below.

PPP daemon: I have a modified PPP daemon, and a PR to match,
so it's working. (#11720)  Packet forwarding enabled in the kernel
is a must, though.  ;->

PPP kernel code: I think it has a strange delay bug (see below)

Of these, I am still working on the Cyclades board to improve flow
control and performance, and the PPP kernel code to eliminate the
strange delays.

Cyclades:
Seems to work OK, except that the driver seems to "miss" interrupts now and then
and I have to make up for this in the callout()/poll() routine, which is neither
efficient, nor "correct".  I *believe* I have a race condition somewhere
when handling the interrupts, but with neither knnowledge of the details
of the semantics of the interrupts in NetBSD, nor docs on the Cyclades
board, I don't want to burn too much time on it.

The flow control in the Cyclades driver seems to be suboptimal.
Again, it works OK with a modem, so I'm not going to mess with it.

NetBSD 1.5 doesn't.)  Mine's not as pretty as I'd like, but it works.
The main thing I changed (besides adding a ton of debug code ;->) was
to add a "manual" invocation of cy_intr() from the cy_poll() routine
to make up for the "lost" interrupts.
If anyone could point me to some info on the details of how interrupts
work on NetBSD/MacPPC, I'd appreciate it.  (i.e. are interrupts
disabled while in the handler?  Are the interrupts level sensitive, or
edge sensitive?  How do you "enable" an interrupt in the hardware
that ensures that you'll immediately get an interrupt as soon
as you "release" it?)


PPP kernel code:
I have a strange problem with delays in networking when connected with PPP.
Its best example behavior is a "ping -i 4 remote.domain.dom".  This results
in a ping time of 4000.xxx msecs quite consistently.  If I have activity
going to the serial line, like other network traffic to the PPP link, then
the response times drop to about 180 msec, which is about right for PPP
on a serial line.  It's like the response to the ping isn't sent back
until the next request arrives.

HOWEVER, this is the really strange part....  If I'm working on this with
my machine "host" running the pppd, and "remote" the machine dialed in, and
I have several telnet windows to "host" from another machine "wstation".
(wstation is simply on the the ethernet network) - then...

Every time I'm typing on one of these telnet sessions, the ping times
between "remote" and "host" drop to about what they "should" be.
As far as I can tell, *any* ethernet traffic from "host" to *anywhere*
(not just "remote") will "trigger" whatever makes the packets get
sent/received.  I'm thinking at this point, that the problem is
not in the responses coming back, but with the requests being
sent out from "host".  I think there is something that is
preventing the outgoing packets until some sort of "trigger" event.

Does anyone have any guesses about this?  Normal ethernet traffic appears
to be unaffected.  It's only the PPP connections that have the ping delay.
Pointers would be appreciated.  I'm getting close to digging into the
networking code in the kernel and trying to figure out what's going on.

This problem does not exist in 1.3.x.  It appears to have appeared in NetBSD
1.4.x on MacPPC.  I have not yet tried to reproduce the problem on my
68K machines with 1.4.x or 1.5.

Many thanks for your help.

Merry Xmas & Happy New Year,

-dgl-