At 7:51 PM -0500 7/26/01, Henry B. Hotz wrote:
>At 7:08 PM -0400 7/26/01, Greg Kritsch wrote:
>>My attempts to execute simple "AT" commands result in utter silence from the
>>modem.  I suppose that could be flow control lines, but somehow I doubt it.
>>Of course, I'm blindly assuming the modem is "Hayes compatible".
>
>I'll have to try it with my work G4 someday.

My experience has been that you can use the serial 0 as long as you don't
touch the tty settings (speed, parity, etc)  If you simply open it and
use it, it'll be OK.  This is apparently why it works for a console.
The moment you fire up pppd, or even another getty, it stops working.
I have never seen serial 1 (printer port) work.  It might be that since OF
doesn't set it up, it isn't right????

>>I understand there is an interrupt latency issue which relates to ppp.
>>People should not assume that this explains all network and serial port
>>problems.  As I understand it, the problem is with soft interrupt delivery.
>>This does not affect "normal" usage, it ONLY affects kernel implemented ppp.
>>Has anyone tried running a userland ppp implementation?
>
>Would that "solve" the problem?  Wouldn't you just see the same 
>thing, plus some additional delays?
>
>In any case do you know if the problem is macppc-specific, or would 
>port-i386 see the same thing?  I have a modem on a 1.4.1 PC and am 
>seeing funny ping times.  Nothing for seconds and then a whole flood 
>of responses.  I suspect NetBSD because I get the same behavior with 
>several ISPs.  Will 1.5.1 make the problem go away?

The problem with latencies is in arch/macppc/macppc/extintr.c, and
is therefore Macppc specific, (unless the i386 code has the same bug).
It causes some soft interrupts to be temporarily lost (until another is
generated).  This was not fixed in 1.5.1 beta 2 in macppc.  I would be
pleasantly surprised if it made 1.5.1.  The PR 12989 remains open.

-dgl-