sparc64/131921: Sending layer-3 traffic over EtherIP tunnel causes kernel panic

[Boris Kochergin]

>Number:         131921
>Category:       sparc64
>Synopsis:       Sending layer-3 traffic over EtherIP tunnel causes kernel panic
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-sparc64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Feb 21 01:10:01 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Boris Kochergin
>Release:        7.1
>Organization:
Polytechnic Institute of NYU
>Environment:
FreeBSD dibner-0-ap 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #2: Fri Jan 30 22:41:46 EST 2009     boris at dibner-0-ap:/usr/obj/usr/src/sys/DIBNER-0-AP  sparc64
>Description:
Configuring an EtherIP tunnel on a sparc64 machine, then attempting to send layer-3 traffic over it, panics the kernel. Here is a sample configuration:

hme0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=b<RXCSUM,TXCSUM,VLAN_MTU>
        ether 08:00:20:f5:65:bb
        inet 128.238.9.196 netmask 0xffffff00 broadcast 128.238.9.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
ath0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:18:e7:32:b7:bd
        media: IEEE 802.11 Wireless Ethernet autoselect <hostap> (autoselect <hostap>)
        status: associated
        ssid acm channel 1 (2412 Mhz 11g) bssid 00:18:e7:32:b7:bd
        authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpower 31.5
        scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7
        roam:rate11g 5 protmode CTS burst dtimperiod 1
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 
        inet6 ::1 prefixlen 128 
        inet 127.0.0.1 netmask 0xff000000 
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 3a:d6:0d:f7:8a:0b
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: gif0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 5 priority 128 path cost 55
        member: ath0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 2 priority 128 path cost 370370
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet 128.238.9.196 --> 128.238.9.199
        inet 10.0.0.2 --> 10.0.0.1 netmask 0xffffff00

If I were to assign an IP address to bridge0 and attempt to do anything with it, or if I attempt to send any layer-3 traffic to 10.0.0.1, the kernel panics. Note that the above machine's main purpose is to bridge traffic between the ath0 device and the endpoint of the gif0 tunnel, and the machine itself generates no layer-3 traffic over the EtherIP tunnel, so it's fine if left alone. The problem does not appear on i386. Here is a backtrace:

Unread portion of the kernel message buffer:
panic: trap: memory address not aligned
cpuid = 1
Uptime: 7m24s
Dumping 768 MB (2 chunks)
  chunk at 0: 536870912 bytes |

#0  0x00000000c029a0d8 in doadump () at /usr/src/sys/kern/kern_shutdown.c:243
243             savectx(&dumppcb);
(kgdb) where
#0  0x00000000c029a0d8 in doadump () at /usr/src/sys/kern/kern_shutdown.c:243
#1  0x00000000c029aab8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0x00000000c029adbc in panic (fmt=0xc06af798 "trap: %s") at /usr/src/sys/kern/kern_shutdown.c:574
#3  0x00000000c0580928 in trap (tf=0xe06dac10) at /usr/src/sys/sparc64/sparc64/trap.c:378
#4  0x00000000c0070fe0 in tl1_trap ()
#5  0x00000000c03a49d0 in ip_output (m=0xfffff80001756000, opt=0x0, ro=0x0, flags=-1066005504, imo=0x201, inp=0x0) at /usr/src/sys/netinet/ip_output.c:152
#6  0x00000000c039beb4 in in_rtalloc_ign (ro=0xfffff80001829172, ignflags=0, fibnum=22098760) at /usr/src/sys/netinet/in_rmx.c:446
#7  0x00000000c0396b68 in in_gif_output (ifp=Variable "ifp" is not available.
) at /usr/src/sys/netinet/in_gif.c:230
#8  0x00000000c03518bc in gif_output (ifp=0xfffff80001078800, m=0xfffff80001829100, dst=0xe06db078, rt=0xfffff800016e00f8) at /usr/src/sys/net/if_gif.c:455
#9  0x00000000c03a55f8 in ip_output (m=0xfffff80001829100, opt=Variable "opt" is not available.
) at /usr/src/sys/netinet/ip_output.c:554
#10 0x00000000c03a7690 in rip_output (m=0xfffff80001829100, so=Variable "so" is not available.
) at /usr/src/sys/netinet/raw_ip.c:414
#11 0x00000000c03a7754 in rip_send (so=0xfffff80001670000, flags=0, m=0xfffff80001829100, nam=0xfffff80001552640, control=0x0, td=0xfffff80001756000) at /usr/src/sys/netinet/raw_ip.c:885
#12 0x00000000c03040ac in sosend_generic (so=0xfffff80001670000, addr=0xfffff80001552640, uio=0xe06db4a8, top=0xfffff80001829100, control=0x0, flags=Variable "flags" is not available.
) at /usr/src/sys/kern/uipc_socket.c:1246
#13 0x00000000c02ff974 in sosend (so=0xfffff80001670000, addr=0xfffff80001552640, uio=0xe06db4a8, top=0x0, control=0x0, flags=0, td=0xfffff80001756000) at /usr/src/sys/kern/uipc_socket.c:1288
#14 0x00000000c03070a4 in kern_sendit (td=0xfffff80001756000, s=3, mp=0xe06db680, flags=0, control=0x0, segflg=Variable "segflg" is not available.
) at /usr/src/sys/kern/uipc_syscalls.c:805
#15 0x00000000c0309f94 in sendit (td=0xfffff80001756000, s=3, mp=0xe06db680, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:742
#16 0x00000000c030a0cc in sendto (td=0xfffff80001756000, uap=0xe06db770) at /usr/src/sys/kern/uipc_syscalls.c:857
#17 0x00000000c0580c4c in syscall (tf=0xe06db880) at /usr/src/sys/sparc64/sparc64/trap.c:610
#18 0x00000000c0070dc0 in tl0_intr ()
#19 0x0000000000000000 in ?? ()
>How-To-Repeat:
Attempt to send layer-3 traffic over an EtherIP tunnel on sparc64. ping(8) will do the trick.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted: