Greg MATTHEWS <G.Matthews@cs.ucl.ac.uk> writes:

> try changing the mac addresses of the ports so that they are different. i know 
> this shouldnt matter if they are on different subnets but i've seen 'leakage' 
> of mac addresses in some network hardware which can get thoroughly confused...
> 
> > le0 at ledma0 slot 4 offset 0x8c00000 level 6: address 08:00:20:7d:86:21
> > le0: 8 receive buffers, 2 transmit buffers
> > qec0 at sbus0 slot 0 offset 0x20000 level 4 (ipl 7): 128K memory
> > qe0 at qec0 slot 0 offset 0x0 rev 1 address 08:00:20:7d:86:21
> > qe1 at qec0 slot 1 offset 0x0 rev 1 address 08:00:20:7d:86:21
> > qe2 at qec0 slot 2 offset 0x0 rev 1 address 08:00:20:7d:86:21
> > qe3 at qec0 slot 3 offset 0x0 rev 1 address 08:00:20:7d:86:21

Mac address probably has nothing to do with an NMI generated by the qec+qe.
On the other hand, the sbus glue logic is buggy and requires an sbus tick
between successive accesses to the mac and dma chip or it generates a bus
fault.  See revision 1.13 of sys/arch/sparc/dev/qe.c in OpenBSD for more
(ugly) details.  I suspect this is the problem (the NetBSD driver was
imported from OpenBSD before this fix).

--Jason L. Wright