Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752435AbcKYGcX convert rfc822-to-8bit (ORCPT ); Fri, 25 Nov 2016 01:32:23 -0500 Received: from rtits2.realtek.com ([211.75.126.72]:39743 "EHLO rtits2.realtek.com.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750995AbcKYGcQ (ORCPT ); Fri, 25 Nov 2016 01:32:16 -0500 Authenticated-By: X-SpamFilter-By: BOX Solutions SpamTrap 5.56 with qID uAP6VImD000936, This message is accepted by code: ctloc85258 From: Hayes Wang To: Mark Lord , David Miller CC: "netdev@vger.kernel.org" , 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//+4SQAAAMTjgAAtfaig Date: Fri, 25 Nov 2016 06:31:18 +0000 Message-ID: <0835B3720019904CB8F7AA43166CEEB2010562B1@RTITMBSV03.realtek.com.tw> References: <95fa9f67-3af6-6749-0e2b-c95406486f7d@pobox.com> <0835B3720019904CB8F7AA43166CEEB201055ED8@RTITMBSV03.realtek.com.tw> <20161124.112152.692025478489876693.davem@davemloft.net> <23e0c132-8844-0a34-3e0b-e412f76493ba@pobox.com> In-Reply-To: <23e0c132-8844-0a34-3e0b-e412f76493ba@pobox.com> 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: 1254 Lines: 33 Mark Lord [mailto:mlord@pobox.com] > Sent: Friday, November 25, 2016 12:44 AM [...] > The bad data in this case is ASCII: > > "SRC=m3400:/ TARGET=/m340" > > This data is what is seen in /run/mount/utab, a file that is read/written over NFS on > each boot. > > "SRC=m3400:/ TARGET=/m3400 ROOT=/ > ATTRS=nolock,addr=192.168.8.1\n" > > But how does this ASCII data end up at offset zero of the rx buffer?? > Not possible -- this isn't even stale data, because only an rx_desc could > be at that offset in that buffer. > > So even if this were a platform memory coherency issue, one should still > never see ASCII data at the beginning of an rx buffer. The driver NEVER > writes anything to the rx buffers. Only the USB hardware ever does. > > And only the r8152 dongle/driver exhibits this issue. > Other USB dongles do not. They *might* still have such issues, > but because they use software checksums, the bad packets are caught/rejected. Do you test it by rebooting? Maybe you could try a patch commit 93fe9b183840 ("r8152: reset the bmu"). However, it should only occur for the first urb buffer after rx is reset. I don't think you would reset the rx frequently, so the situation seems to be different. Best Regards, Hayes