On the nose!  Cool.  Many thanks to der Mouse.  I owe him some cheese. ;->

I made the following change - it's not "right", but it solves my problem,
and seems not to have adverse effect.

(sys/arch/macppc/macppc/extintr.c
/*      $NetBSD: extintr.c,v 1.12.4.1 2000/11/01 16:26:07 tv Exp $      */)

charm$ diff -c extintr.c ~/extintr.c
*** extintr.c   Wed Nov  1 10:26:07 2000
--- /home/user/donlee/extintr.c Mon Jan  1 14:32:50 2001
***************
*** 620,625 ****
--- 620,626 ----
        int hwpend;
        int emsr, dmsr;
        static int processing;
+       int tryit;

        if (processing)
                return;
***************
*** 667,673 ****
                softserial();
                intrcnt[CNT_SOFTSERIAL]++;
        }
!       ipending &= pcpl;
        cpl = pcpl;     /* Don't use splx... we are here already! */
        asm volatile("mtmsr %0" :: "r"(emsr));
        processing = 0;
--- 668,675 ----
                softserial();
                intrcnt[CNT_SOFTSERIAL]++;
        }
!       tryit = (1 << SIR_CLOCK) | (1 << SIR_NET) | (1 << SIR_SERIAL);
!       ipending &= (pcpl | tryit);
        cpl = pcpl;     /* Don't use splx... we are here already! */
        asm volatile("mtmsr %0" :: "r"(emsr));
        processing = 0;

ping times are now around 16 ms, which is about what I expect.

Life is good.

-dgl-

P.S. I suspect that this may be similar to my problem with the "lost
interrupts" in the Cyclades serial driver, but I don't understand the
code enough to play with it....

>> 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