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