Subject: Re: unaligned access in in_delayed_cksum()
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Jason R Thorpe <thorpej@wasabisystems.com>
List: tech-net
Date: 09/29/2002 17:32:32
On Sun, Sep 29, 2002 at 06:16:51PM +0200, Manuel Bouyer wrote:

 > First I have a question: are hadware-assised checksums supposed to work
 > with VLAN ? I found nothing in the code that could pass ec_capenable

That really depends on the interface.  I suppose we need another cap flag
for it.

For example, interfaces which do VLAN encap/decap in hardware can generally
also do the checksum offload.  Other interfaces, like the Intel i8254x, can
do the checksum offload even if it's not doing the VLAN encap/decap, because
the driver tells it explicitly where in the frame to start the checksum
(actually, it looks like I need to add VLAN support to the wm driver's
checksum offload :-)

However, interfaces like the 3c905, which have a very simple (a few flag
bits only) checksum offload api won't be able to handle checksum offload
on VLANs.

 > from the parent interface to the ip stack though if_vlan. Maybe I should
 > just set *4csum on all vlan interfaces too.
 > 
 > I tried enabling ip4csum|tcp4csum|udp4csum on ti0 only (not the vlan,
 > didn't have time).
 > Almost immediatly the machine paniced with:
 > CPU 0: fatal kernel trap:
 > 
 > CPU 0    trap entry = 0x4 (unaligned access fault)
 > CPU 0    a0         = 0xfffffc000599757b
 > CPU 0    a1         = 0xd
 > CPU 0    a2         = 0x2
 > CPU 0    pc         = 0xfffffc0000493770
 > CPU 0    ra         = 0xfffffc00004936f0
 > CPU 0    pv         = 0xffffffffffff0001
 > CPU 0    curproc    = 0x0
 > 
 > gdb shows that pc is in in_delayed_cksum() line 814:
 > 0xfffffc0000493770 is in in_delayed_cksum (/home/src/sys/arch/alpha/compile/DISCO/../../../../netinet/ip_output.c:814).
 > 809                     printf("in_delayed_cksum: pullup len %d off %d proto %d\n",
 > 810                         m->m_len, offset, ip->ip_p);
 > 811                      */
 > 812                     m_copyback(m, offset, sizeof(csum), (caddr_t) &csum);
 > 813             } else
 > 814                     *(u_int16_t *)(mtod(m, caddr_t) + offset) = csum;
 > 815     }
 > 816     
 > 817     /*
 > 818      * Determine the maximum length of the options to be inserted;
 > 
 > Any idea ?

This is a little surprising -- if the interface doesn't have any addresses,
what is it doing sending out packets?

 > If I enable ip4csum|tcp4csum|udp4csum on both ti0 and the associated vlans
 > before assigning IP addresses, all seem to go well.

Well, we need some method of communicating flag changes like this between
the vlan interface and the parent interface.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>