[OpenWrt-Devel] [PATCH] axs10x: initilaze network for wireless access-point

Felix Fietkau nbd at openwrt.org
Mon Nov 23 12:38:16 EST 2015

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 at lists.openwrt.org

More information about the openwrt-devel mailing list