nmap UDP scan against 8.0-CURRENT -> fatal trap 12

Hey everybody,

I discovered a reproducible network-triggerable panic on my -CURRENT  
box (r196074). The NIC is a nfe (nForce4 SLI) in case it matters.
The backtrace differs slightly (the first one had less ??'s, but I'm  
not sure I ran the same scan that time).

I ran the following on a Linux box, while trialling zenmap ("Slow  
comprehensive scan" - and needless to say .1.10 is the FreeBSD box):
nmap -sS -sU -T4 -A -v -PE -PP -PS21,22,23,25,80,113,31339 - 
PA80,113,443,10042 -PO --script all 192.168.1.10
(nmap -sU -A -v 192.168.1.10 also triggers a panic within 3 seconds,  
at most.)

Starting Nmap 5.00 ( http://nmap.org ) at 2009-08-09 17:52 CEST
NSE: Loaded 59 scripts for scanning.
Initiating ARP Ping Scan at 17:52
Scanning 192.168.1.10 [1 port]
Completed ARP Ping Scan at 17:52, 0.01s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 17:52
Scanning chaos (192.168.1.10) [1000 ports]
Discovered open port .../tcp on 192.168.10
Discovered open port 80/tcp on 192.168.1.10
Discovered open port .../tcp on 192.168.10
... and a few more
Completed SYN Stealth Scan at 17:52, 5.04s elapsed (1000 total ports)
Initiating UDP Scan at 17:52
[... the FreeBSD target box panicked here here, within a second or two]
-----------------------------------------------------------------

On the console:
Limiting closed port RST response from 276 to 200 packets/sec
Limiting closed port RST response from 239 to 200 packets/sec
Limiting closed port RST response from 280 to 200 packets/sec
Limiting closed port RST response from 319 to 200 packets/sec
Limiting icmp unreach response from 214 to 200 packets/sec
Limiting icmp unreach response from 275 to 200 packets/sec
Limiting icmp unreach response from 449 to 200 packets/sec

core.txt:

Unread portion of the kernel message buffer:
Limiting icmp unreach response from 449 to 200 packets/sec


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x18
fault code      = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff805d2722
stack pointer           = 0x28:0xffffff803e76f980
frame pointer           = 0x28:0xffffff803e76f990
code segment        = base 0x0, limit 0xfffff, type 0x1b
				= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process     = 846 (nfsd: service) [NOTE: nfsd was not in use,  
merely running]
panic: from debugger
cpuid = 0
KDB: stack backtrace:
Uptime: 8m48s
Physical memory: 2029 MB
Dumping 1625 MB: ...

#11 0xffffffff805dba87 in calltrap ()    at /usr/src/sys/amd64/amd64/ 
exception.S:224
#12 0xffffffff805d2722 in xdrmbuf_inline (xdrs=0xffffff803e76fa30,  
len=4)
     at /usr/src/sys/xdr/xdr_mbuf.c:302
#13 0xffffffff805d2b90 in xdrmbuf_getlong (xdrs=0xffffff803e76fa30,
     lp=0xffffff803e76f9e0) at /usr/src/sys/xdr/xdr_mbuf.c:147
#14 0xffffffff805d1a4d in xdr_int (xdrs=Variable "xdrs" is not  
available.
) at /usr/src/sys/xdr/xdr.c:111
#15 0xffffffff80554ef4 in xdr_callmsg (xdrs=0xffffff803e76fa30,     
cmsg=0xffffff803e76fb70) at /usr/src/sys/rpc/rpc_callmsg.c:188
#16 0xffffffff80559c60 in svc_dg_recv (xprt=Variable "xprt" is not  
available.
) at /usr/src/sys/rpc/svc_dg.c:216
#17 0xffffffff80557910 in svc_run_internal (pool=0xffffff00027acc00,
     ismaster=0) at /usr/src/sys/rpc/svc.c:797
#18 0xffffffff8055811b in svc_thread_start (arg=Variable "arg" is not  
available.
)    at /usr/src/sys/rpc/svc.c:1198
#19 0xffffffff80341008 in fork_exit (
     callout=0xffffffff80558110 <svc_thread_start>,  
arg=0xffffff00027acc00,
     frame=0xffffff803e76fc80) at /usr/src/sys/kern/kern_fork.c:838
#20 0xffffffff805dbf5e in fork_trampoline ()    at /usr/src/sys/amd64/ 
amd64/exception.S:561
#21 0x0000000000000010 in ?? ()
#22 0x00007fffffffe710 in ?? ()
...
#47 0x0000000000000000 in ?? ()
#48 0xffffffff808acf00 in affinity ()
#49 0xffffff0002d9d390 in ?? ()
#50 0xffffff803e76f200 in ?? ()
#51 0xffffff803e76f1b8 in ?? ()
#52 0xffffff0002336720 in ?? ()
#53 0xffffffff80391c2d in sched_switch (td=0xffffffff80558110,
     newtd=0xffffff00027acc00, flags=Variable "flags" is not available.
) at /usr/src/sys/kern/sched_ule.c:1858

-----------------------------------------

I'll be honest and say that FreeBSD doesn't feel very stable for me...  
Yeah, sure, I use experimental features which causes many of my panics  
(like ZFS) and run -CURRENT, but will really all issues like this one  
be fixed in time for 8.0-RELEASE? It's pretty ugly that I can panic it  
via the network every try, in literally 2-3 seconds.

Regards,
Thomas