>> You can watch the lights, and see that the ping goes out, the
>> response comes right back, and the message to the screen gets output
>> [at next network activity].  As far as I can tell, the incoming
>> packet from the PPP interface is getting queued, waiting for a
>> software interrupt, and the software interrupt is not getting
>> triggered for some reason.
>
>Hmm.  Is it any network activity, or any network activity on the PPP
>line?  Sounds a bit like a missing schednetisr(), but that's in an MI
>part of PPP, so if it were missing, PPP would lose on all arches.

It's any network activity.  As far as I can tell, any network packet
on any interface that goes in or out will trigger one of these "sluggish"
packets to arrive.  I can do this with a ping from anywhere to anywhere
on any media, as long as either the pinger or the pingee is the ppp host.

One exception is if I go to the ppp host and do a "ping localhost > /dev/null".
This has no effect.  If I let the output come to the screen though, then
it "fixes" the problem.  This, I'm guessing, is because  the output
is getting sent out over ethernet, and triggering the goodness.

>Hmm, schednetisr()'s implementation is MD.  Maybe check that the macppc
>version doesn't mishandle NETISR_PPP?  I don't see anything obviously
>wrong with it through from schednetisr to pppintr, but that's only a
>couple minutes' code reading.

I've dug into the code far enough to find the net/netisr_dispatch.h code, and
it has the NETISR_PPP entry - last, but it looks like it's there.
I haven't figured out an easy way to tell if it's being invoked properly
though.  printf() in the kernel has its limitations. ;->

>> I'm betting that this has not been addressed because no one has PPP
>> working on MacPPC - (serial ports dont work....)
>
>In what sense do they not?  I'm seeing some odd brokenness on the
>console serial port on my 4400/200; it works okay for a while (at least
>FSVO "a while"), but then it acts as though the receiver falls over -
>it just stops paying attention to input characters.  For a while I
>thought the whole machine was hanging, but then I noticed it happened
>only when I was actively typing.  Shortly thereafter, I got it up
>enough to talk to the net, and next time it "hung", sure enough, it
>still answered the net.  Is this sort of experience common?

Yes.  As a serial console, the serial port (modem) seems to work.
I have not pushed on that very hard.  My goal is to get
dial-up PPP working.

I've had zero luck getting the built-in serial ports to work for PPP.
As a simpler case, I've tried running various things on the built in
/dev/tty01 like a getty on /dev/tty01, and this
does not work.

The console on /dev/tty00 seems to work, but if you mess with it, by
trying to change the speed or hooking up a modem, it stops working.

No crashes, but it normally just goes deaf and dumb.

Thanks for your help.

-dgl-