Subject: Re: Does PPP work on MacPPC?
To: Donald Lee <donlee_ppc@icompute.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-macppc
Date: 01/01/2001 11:16:47
> ping sends packet
> (unknown regions...)
> pppintr() gets called.
> pppintr calls inproc(), which does a schednetisr(NETISR_IP);
> >>DELAY..... (can be cut short at any time by any network packet)
> ipintr() gets invoked, and the ping "output" completes.
> What's the delay?
I *suspect* the delay is "ipending &= pcpl" four lines from the end of
do_pending_int (arch/macppc/macppc/extintr.c). The reason is:
- some code (hw interrupt?) ends up invoking do_pending_int(),
presumably from splx().
- do_pending_int() calls various things, one of which calls
schednetisr(NETISR_IP), which calls setsoftnet(), which sets the
SIR_NET bit in ipending.
- do_pending_int regains control and eventually does that line I
quoted, "ipending &= pcpl". Because SIR_NET was not blocked on entry
to do_pending_int, this discards the just-set SIR_NET bit.
- It sits there until something else, something not called from
do_pending_int(), provokes a setsoftnet(), which works (ext_intr or
ext_intr_openpic does splhigh(), then calls interrupt handler;
handler calls setsoftnet() (perhaps indirectly), setting ipending
bit; when ext_intr{,_openpic} does splx(), do_pending_int is invoked
and handles ipending).
It looks to me as though there is similar risk for other soft
interrupts. I suspect do_pending_int() needs a bit of a rethink.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B