Bernhard Schmidt wrote:
> I've hit another kernel oops with 2.6.20-rc3 on i386 platform. It is
> reproducible, as soon as I load nf_conntrack_ipv6 and try to send
> something large (scp or so) inside an OpenVPN tunnel on my client
> (patched with UDPv6 transport) the router (another box) OOPSes.
> 
> tcpdump suggests the problem appears as soon as my client sends
> fragmented UDPv6 packets towards the destination. It does not happen
> when nf_conntrack_ipv6 is not loaded. This is the OOPS as dumped from
> the serial console:
> 
> heimdall login: Oops: 0000 [#1]
> Modules linked in: sit sch_red sch_htb pppoe pppox ppp_generic slhc
> xt_CLASSIFY ipt_TOS xt_length ipt_tos ipt_TCPMSS xt_tcpudp
> ipt_MASQUERADE xt_state iptable_mangle iptable_filter
>  iptable_nat nf_nat nf_conntrack_ipv4 ip_tables x_tables
> nf_conntrack_ipv6 nf_conntrack nfnetlink
> CPU:    0
> EIP:    0060:[<00000001>]    Not tainted VLI
> EFLAGS: 00010246   (2.6.20-rc3 #2)
> EIP is at 0x1
> eax: cd215bc0   ebx: cd1f3160   ecx: cc59002a   edx: cd215bc0
> esi: cd215bc0   edi: cd215bc0   ebp: 00000000   esp: c030bd3c
> ds: 007b   es: 007b   ss: 0068
> Process swapper (pid: 0, ti=c030a000 task=c02e93a0 task.ti=c030a000)
> Stack: c0212cc4 00000004 cc83f160 cd2130c0 cd215bc0 cd2130c0 cd215bc0
> c021734b
>        c030bdb4 c0307a60 0000000a cceee800 cceee800 cd215bc0 cd1f3160
> 00000000
>        c021896b c0307a60 cd215bc0 cd215bc0 cceee800 cd1f3160 c025f1c6
> 00000000
> Call Trace:
>  [<c0212cc4>] __kfree_skb+0x84/0xe0
>  [<c021734b>] dev_hard_start_xmit+0x1bb/0x1d0
>  [<c021896b>] dev_queue_xmit+0x11b/0x1b0
>  [<c025f1c6>] ip6_output2+0x276/0x2b0
>  [<c025ed30>] ip6_output_finish+0x0/0xf0
>  [<c025fc0a>] ip6_output+0x90a/0x940
>  [<c013e9e5>] cache_alloc_refill+0x2c5/0x3f0
>  [<c0212eed>] pskb_expand_head+0xdd/0x130
>  [<c02608d5>] ip6_forward+0x465/0x4b0
>  [<c02618c6>] ip6_rcv_finish+0x16/0x30
>  [<ce81a056>] nf_ct_frag6_output+0x86/0xb0 [nf_conntrack_ipv6]

Does this patch help?