kern/41588: panic: m_copym: m == 0, off 904

[raeburn%raeburn.org@localhost]

>Number:         41588
>Category:       kern
>Synopsis:       panic: m_copym: m == 0, off 904
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jun 13 11:55:00 +0000 2009
>Originator:     Ken Raeburn
>Release:        NetBSD 5.0
>Organization:
        
>Environment:
System: NetBSD raeburn.org 5.0 NetBSD 5.0 (GENERIC) #0: Sun Apr 26 18:50:08 UTC 
2009 
builds%b6.netbsd.org@localhost:/home/builds/ab/netbsd-5-0-RELEASE/i386/200904260229Z-obj/home/builds/ab/netbsd-5-0-RELEASE/src/sys/arch/i386/compile/GENERIC
 i386
Architecture: i386
Machine: i386
>Description:

I've been seeing this problem for a while with the 4.0.1 kernel, but
hadn't grabbed a stack trace (swap too small for crash dumps) and
figured maybe 5.0 would fix it, but apparently not.

Fairly frequently -- sometimes two or three times in a day -- the
NetBSD box I'm using as a router (file server, DNS server, etc)
crashes with this message.  It's always the same offset (904)
reported.  It doesn't seem to relate to particularly heavy use of the
network.

After updating to 5.0 this morning, it only took a few hours for it to
trigger again.  I had enabled ddb on panic this time, so here's the
trace info I jotted down:

breakpoint(...)
panic(...)
m_copym0(1, 0, 238, 1, 0, cbe4ec10, cc623090, 24c, 238, 14) at +0x3e3
ip_fragment(c2a6c900, cc623090, 5dc, 2, 4, 0, c2a75ee8, c2a6c9d0, 14, c29bf4d0) 
at +0xe6
ip_output(c2a6c900, 0, c2a8fe10, 0, 0, 0, cbe4ed20, c014fde8, 1408c000, 0) at 
+0xb31
in_gif_output(...) at +0x2e5
gifintr(...) at +0xe0
softint_dispatch(...) at +0x7c

I'm using ipfilter, ipnat, linuxigd from pkgsrc-wip (which would just
be tweaking the ipf rules), two gif tunnels (though one should be used
infrequently, and the other has a remote endpoint host that's dead),
and an stf interface; no ipsec or pf.

My ipfilter rules often use "pass out quick on tlp2 to gif4 ..." to
direct certain traffic over a gif tunnel; mostly just responses to
incoming traffic using a public IP address that comes in over the
tunnel.  Most of my outgoing IPv4 traffic initiated locally uses NAT
instead and goes directly out through my local ISP.  My IPv6 traffic
has a default route through stf0.

>How-To-Repeat:
        ?
>Fix:
        ?