On 16-11-04 09:50 AM, Mark Lord wrote: > Yeah, the device or driver is definitely getting confused with rx_desc > structures. > I added code to check for unlikely rx_desc values, and it found this for > starters: > > rx_desc: 00480801 00480401 00480001 0048fc00 0048f800 0048f400 pkt_len=2045 > rx_data: 00 f0 48 00 00 ec 48 00 00 e8 48 00 00 e4 48 00 00 e0 48 00 00 dc 48 > 00 00 d8 48 00 00 d4 > 48 00 > rx_data: 00 d0 48 00 00 cc 48 00 00 c8 48 00 00 c4 48 00 00 c0 48 00 00 bc 48 > 00 00 b8 48 00 00 b4 > 48 00 > rx_data: 00 b0 48 00 00 ac 48 00 00 01 00 00 81 ed 00 00 00 01 00 00 00 00 00 > 00 00 00 00 02 4d ac > 00 00 > rx_data: 10 00 ff ff ff ff 00 00 01 28 83 d6 ff 6d 00 20 25 b1 58 1b 68 ff 00 > 05 20 01 56 41 17 35 > 00 00 > ... > > The MTU/MRU on this link is the standard 1500 bytes, so a pkt_len of 2045 > isn't valid here. > And the rx_desc values look an awful lot like the rx_data values that follow > it. > > There's definitely more broken here than just TCP RX checksums.
I spent a bit more time on this again today, and made progress. The issue seems to be stale rx buffers. I'll discuss further offline with Hayes Wang. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com
