From: Harald Welte <laforge@xxxxxxxxxxxx> Date: Sat, 30 Sep 2006 22:20:40 +0200 > Kernel unaligned access at TPC[10022cf0] ipv6_rcv+0xb8/0x320 [ipv6] > Kernel unaligned access at TPC[10023800] __ipv6_addr_type+0x8/0x140 [ipv6] > Kernel unaligned access at TPC[1002fd64] fib6_lookup_1+0x2c/0x120 [ipv6] > Kernel unaligned access at TPC[10093878] tcp_error+0x40/0x2c0 [nf_conntrack] > Kernel unaligned access at TPC[1004ce54] nf_ip6_checksum+0x13c/0x1c0 [ipv6] > Kernel unaligned access at TPC[1004ce58] nf_ip6_checksum+0x140/0x1c0 [ipv6] > Kernel unaligned access at TPC[1004ce60] nf_ip6_checksum+0x148/0x1c0 [ipv6] I think for all of these cases the IPv6 header is not 4-byte aligned in the SKB. The first case is simply ipv6_hdr->version which GCC turns into a load of the first 4 byte word of the headers, then a mask+compare. And this is fine becasue due to the "struct in6_addr", gcc may assume that the ipv6 header struct is at least 4 bytes aligned since in6_addr contains an array of u32[]'s. What kind of input path is this packet coming from? Is it using some kind of encapsulation? It's odd for it to not be 4 byte aligned, you would get the same kind of unaligned accesses for an ipv4 header if it were misaligned like this. - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
