Subject: Re: Does PPP work on MacPPC?
To: None <firstname.lastname@example.org>
From: Donald Lee <email@example.com>
Date: 12/31/2000 23:59:36
>> 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.