Has anybody else seen one of these?  I got one on the reveive end 
of a UDP-Blast-em test.  I was running on a point-point link using 
the fxp/82558 driver. 

I have a crash dump.  Is there likely to be anything useful in it?  
If so, what should I type?

How hard should I try to make it happen again?  This test uses (misuses?) 
a lot of network buffers.  It's reasonably likey to provoke troubles 
if any code doesn't handle the no-buffer case correctly.

I'm also getting the fxp1: device timeout messages on the send side 
or on the side that crashed with different tests that generate traffic 
going in the other direction. 

------

I had troubles getting a dump.  On the first try with "call cpu_reboot(0x100)" 
I got a mcpl reentrance from 82557.c line 1593.  That was also the 
previous call. 

I assume it was trying to turn off the network drivers so memory 
wouldn't get smashed by an arriving packet.  Should network drivers 
have a lightweight just-stop-everything hook for this purpose? 

Next, I tried "call cpu_reboot(0x104)".  It took a long long time 
for the dump.  The screen counted down from 512 at about 1 per second.  
That machine has 512 megabytes.  I guess 1 megabyte/second is within 
reason for a dumb/simple driver but it felt like a long time. 

After that, I got another mclpl reentrance.  This time it said uipc_mbuf.c 
line 358.

At that point, I was out of ideas so I power cycled. 
 
Then it told me there wasn't enough room in /var.  I made more and 
rebooted and now I have: 

  mckinley% ls -l /var/crash/
  total 131874
  -rw-------  1 root  wheel          2 Jun  4 15:04 bounds
  -rw-------  1 root  wheel          5 May 28 13:52 minfree
  -rw-------  1 root  wheel    1636281 Jun  4 15:07 netbsd.0.Z
  -rw-------  1 root  wheel  133312669 Jun  4 15:07 netbsd.0.core.Z
  mckinley%