On 2015-11-23 17:20, Alexey Brodkin wrote: > Well in ARCv1 we can only handle unaligned access in software. > Here I mean handle unaligned exception in Linux kernel and copying > data back to caller. But this essentially comes with performance penalty. > > On ARCv2 we may have that feature right in hardware though still not > necessary - remember ARC is highly configurable architecture and real > users (I mean vendors of ASICs) may use or not use each particular feature. > > But I'd say unaligned access highlights a problem here (and I'm not yet > to blame yet anybody for now). Because what happens compiler attempts > to use half-word (two-bytes) read () on a byte-aligned address > (something like 0x4000_0001). And that happens in ether_addr_equal() > comment for which clearly states: > https://github.com/torvalds/linux/blob/master/include/linux/etherdevice.h#L308 > ---------------->8----------------- > Please note: addr1 & addr2 must both be aligned to u16. > ---------------->8----------------- > > So what we seeing here "src = eth_hdr(skb)->h_source" is not 2-bytes > aligned (=0x9e3c766b) which I believe should not be the case , right? > > I mean even if unaligned accesses could be supported something doesn't > match expectations of ether_addr_equal(). An unaligned access in that place usually indicates a driver bug. Where is that packet coming from, ethernet or wireless? Maybe you can see that in the stack trace - if not, you can probably add a selective dump_stack() call in the right place.
- Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
