Izumi Tsutsui pointed out;

>>      -> overblocking, possibly causes missing hardclock()
>>
>>     The access to `netisr' should be protected by splnet().
>>     Currently this is not real problem due to above overblocking.
>
> I think current arch/mips/mips/trap.c:netintr() still has
> this problem, but I wonder what is the right solution.

Welcome to "spl(9) dungeon," one of the most awful aspect of classic
UNIX internals.   The issue is complicated by the parallel and somehow
conflicting notion of "interrupt priorities" fabricated by the way how
classic UNIX (=NetBSD) kernel is organized and how the hardware
circuit (CPU design and real devices) is wired.

Now, recognizing I provide no answer to Mr. Tsutsui, I would like bring
a rather obscure point instead.   The existence of netisr variable is an
in-appropriate.   Delivering crafted protocol controlling thread via
netintr() is e-v-i-l.   We're going toward SMP with fine-grained lock
and lightweight in-kernel threading anyway, why should we stay with
the old-and-archaic leftover of softintr()/netintr() scheme?  I want
to see a cool solution in MI area.

Toru Nishimura/ALKYL Technology