Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941132AbcKXN1H convert rfc822-to-8bit (ORCPT ); Thu, 24 Nov 2016 08:27:07 -0500 Received: from rtits2.realtek.com ([211.75.126.72]:41847 "EHLO rtits2.realtek.com.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S940580AbcKXN1F (ORCPT ); Thu, 24 Nov 2016 08:27:05 -0500 Authenticated-By: X-SpamFilter-By: BOX Solutions SpamTrap 5.56 with qID uAODQub9022992, This message is accepted by code: ctloc85258 From: Hayes Wang To: Mark Lord , "netdev@vger.kernel.org" CC: nic_swsd , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" Subject: RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Thread-Topic: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Thread-Index: AQHSO+t3nHKkZLLsBUqa3CUPsCXz6KDci+AwgAAm4ICAAaIjoP//1LUAgAfJkeCAAC16gIAAmNB+///IdICAAR1zgIAAiCTw Date: Thu, 24 Nov 2016 13:26:55 +0000 Message-ID: <0835B3720019904CB8F7AA43166CEEB201055ED8@RTITMBSV03.realtek.com.tw> References: <1394712342-15778-226-Taiwan-albertk@realtek.com> <1394712342-15778-227-Taiwan-albertk@realtek.com> <0835B3720019904CB8F7AA43166CEEB20105013E@RTITMBSV03.realtek.com.tw> <0835B3720019904CB8F7AA43166CEEB201050B7E@RTITMBSV03.realtek.com.tw> <0835B3720019904CB8F7AA43166CEEB2010517CE@RTITMBSV03.realtek.com.tw> <0835B3720019904CB8F7AA43166CEEB201051D51@RTITMBSV03.realtek.com.tw> <95fa9f67-3af6-6749-0e2b-c95406486f7d@pobox.com> In-Reply-To: Accept-Language: zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.177.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1092 Lines: 25 Mark Lord [mailto:mlord@pobox.com] > Sent: Thursday, November 24, 2016 8:31 PM [...] > Nope. Guard zones did not fix it, so it's probably not a prefetch issue. > Oddly, adding a couple of memory barriers to specific places in the driver > does help, A LOT. Still not 100%, but it did pass 1800 reboot tests over night > with only three bad rx_desc's reported. > > That's a new record here for the driver using kmalloc'd buffers, > and put reliability on par with using non-cacheable buffers. > > Any way we look at it though, the chip/driver are simply unreliable, > and relying upon hardware checksums (which fail due to the driver > looking at garbage rather than the checksum bits) leads to data corruption. I don't think the garbage results from our driver or device. If it is the issue about memory, I think the host driver ought to deal with it, because it handles the DMA. Besides, it doesn't seem to occur for all platforms. I have tested the iperf more than 26 hours, and it still works fine. I think I would get the same result on x86 or x86_64 platform. Best Regards, Hayes