On Mon, Jul 14, 2014 at 11:35 PM, Rafał Miłecki <zaj...@gmail.com> wrote: > On 14 July 2014 18:44, Jonas Gorski <j...@openwrt.org> wrote: >> On Mon, Jul 14, 2014 at 6:23 PM, Felix Fietkau <n...@openwrt.org> wrote: >>> It looks to me like the hardware is overwriting the skb shared info (at >>> the end of the skb data buffer), possibly because the configured maximum >>> frame length may be too big for the buffer. >>> >>> If I were to speculate wildly, I would guess that B44_RXMAXLEN refers to >>> the maximum frame length, not the maximum buffer length - and in the >>> code, it's being fed with the maximum buffer length. >>> This would allow the hardware to receive slightly oversized frames which >>> can corrupt the skb. >> >> Since there is a public datasheet[1], this is easily verifiable, and >> it looks you are right: >> >> "Receive Maximum Length Register (RcvLength, Offset 0x404): >> >> The value stored in this register specifies the largest valid Ethernet >> Frame to be received." >> >> The same is true for the XmtMaxLength register, which is also set "too >> large" (it defaults to 1518). > > I wonder what's the point of that register if we set length per-skb > anyway (b44_alloc_rx_skb): > ctrl = (DESC_CTRL_LEN & RX_PKT_BUF_SZ);
As far as I understand, the hardware is capable of letting packets span several descriptors, so if you expect to have mostly small packets (e.g. < 600 bytes), you could save memory by only using 600 byte rx buffers, but still allowing the engine to receive full 1518 bytes frames, then split over several descriptors. Jonas _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
