On 16-11-09 08:09 AM, Hayes Wang wrote:
> Mark Lord [mailto:ml...@pobox.com]
..
>> 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
Mark Lord [mailto:ml...@pobox.com]
> Sent: Friday, November 04, 2016 9:50 PM
[...]
> 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
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
> r
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
On 16-11-02 02:29 PM, Mark Lord wrote:
I have poked at it some more, and thus far it appears that it is
only necessary to disable TCP rx checksums. The system doesn't crash
when only IP/UDP checksums are enabled, but does when TCP checksums are on.
This happens regardless of whether RX_AGG is
On 16-11-03 04:56 AM, Hayes Wang wrote:
> Mark Lord [mailto:ml...@pobox.com]
>> Sent: Thursday, November 03, 2016 2:30 AM
>> To: Hayes Wang; David Miller
> [...]
>> I have poked at it some more, and thus far it appears that it is
>> only necessary to disable TCP rx checksums. The system doesn't cr
Mark Lord [mailto:ml...@pobox.com]
> Sent: Thursday, November 03, 2016 2:30 AM
> To: Hayes Wang; David Miller
[...]
> I have poked at it some more, and thus far it appears that it is
> only necessary to disable TCP rx checksums. The system doesn't crash
> when only IP/UDP checksums are enabled, bu
On 16-10-31 04:14 AM, Hayes Wang wrote:
The r8152 driver has been broken since (approx) 3.16.xx
when support was added for hardware RX checksums
on newer chip versions. Symptoms include random
segfaults and silent data corruption over NFS.
The hardware checksum logig does not work on the VER_02
On 16-10-31 04:14 AM, Hayes Wang wrote:
>
> Our hw engineer says only VER_01 has the issue about rx checksum.
> I need more information for checking it.
I've been doing driver work for Linux since 1991,
and learned long ago not to trust engineering specs 100%.
Get yourself a Raspberry Pi v1, set
> >>> The r8152 driver has been broken since (approx) 3.16.xx
> >>> when support was added for hardware RX checksums
> >>> on newer chip versions. Symptoms include random
> >>> segfaults and silent data corruption over NFS.
> >>>
> >>> The hardware checksum logig does not work on the VER_02
> >>>
From: Mark Lord
Date: Sun, 30 Oct 2016 22:07:25 -0400
> On 16-10-30 08:57 PM, David Miller wrote:
>> From: Mark Lord
>> Date: Sun, 30 Oct 2016 19:28:27 -0400
>>
>>> The r8152 driver has been broken since (approx) 3.16.xx
>>> when support was added for hardware RX checksums
>>> on newer chip ver
On 16-10-30 08:57 PM, David Miller wrote:
> From: Mark Lord
> Date: Sun, 30 Oct 2016 19:28:27 -0400
>
>> The r8152 driver has been broken since (approx) 3.16.xx
>> when support was added for hardware RX checksums
>> on newer chip versions. Symptoms include random
>> segfaults and silent data cor
From: Mark Lord
Date: Sun, 30 Oct 2016 19:28:27 -0400
> The r8152 driver has been broken since (approx) 3.16.xx
> when support was added for hardware RX checksums
> on newer chip versions. Symptoms include random
> segfaults and silent data corruption over NFS.
>
> The hardware checksum logig d
13 matches
Mail list logo
