Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752632AbcKYGMO convert rfc822-to-8bit (ORCPT ); Fri, 25 Nov 2016 01:12:14 -0500 Received: from rtits2.realtek.com ([211.75.126.72]:57679 "EHLO rtits2.realtek.com.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751645AbcKYGL7 (ORCPT ); Fri, 25 Nov 2016 01:11:59 -0500 Authenticated-By: X-SpamFilter-By: BOX Solutions SpamTrap 5.56 with qID uAP6BIqS026355, 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//+oW4AALrMAoA== Date: Fri, 25 Nov 2016 06:11:18 +0000 Message-ID: <0835B3720019904CB8F7AA43166CEEB201056266@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> <0835B3720019904CB8F7AA43166CEEB201055ED8@RTITMBSV03.realtek.com.tw> 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: 1575 Lines: 43 Mark Lord [mailto:mlord@pobox.com] > Sent: Thursday, November 24, 2016 11:25 PM [...] > x86 has near fully-coherent memory, so it is the "easy" platform > to get things working on. But Linux supports a very diverse number > of platforms, with varying degrees of cache/memory coherency, > and it can be tricky for things to work correctly on all of them. However, I have test iperf on raspberry pi v1 which you suggest for more than one day. I still couldn't reproduce your issue. > If you are testing with the driver as currently in 4.4.34, > then you won't even notice when things are screwing up, > because the driver just silently drops packets. > Or it passes them on without noticing that they have bad data. I only drop the packet silently when the rx descriptor outside the urb buffer. Then, I check the rx descriptor before checking the length of the packet. > Here (attached) is the instrumented driver I am using here now. > I suggest you use it or something similar when testing, > and not the stock driver. I would test it again with your driver. [...] > Also, unrelated, but inside r8152_submit_rx() there is this code: > > /* The rx would be stopped, so skip submitting */ > if (test_bit(RTL8152_UNPLUG, &tp->flags) || > !test_bit(WORK_ENABLE, &tp->flags) > || !netif_carrier_ok(tp->netdev)) > return 0; > > If that "return 0" statement is ever executed, doesn't it result > in the loss/leak of a buffer? They would be found back by calling rtl_start_rx(), when the rx is restarted. Best Regards, Hayes