Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753868AbcKINKO (ORCPT ); Wed, 9 Nov 2016 08:10:14 -0500 Received: from rtits2.realtek.com ([211.75.126.72]:40798 "EHLO rtits2.realtek.com.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753364AbcKINKM (ORCPT ); Wed, 9 Nov 2016 08:10:12 -0500 Authenticated-By: X-SpamFilter-By: BOX Solutions SpamTrap 5.56 with qID uA9D9r0I002386, This message is accepted by code: ctloc85258 From: Hayes Wang To: Mark Lord , David Miller CC: nic_swsd , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH net] r8152: Fix broken RX checksums. Thread-Topic: [PATCH net] r8152: Fix broken RX checksums. Thread-Index: AQHSMypesTCefyf3Q0+uiksQ3ScZXKDCK5vwgANWLgCAAXP9gP//rM8AgAG1vQCACFKl4A== Date: Wed, 9 Nov 2016 13:09:53 +0000 Message-ID: <0835B3720019904CB8F7AA43166CEEB20104A0FD@RTITMBSV03.realtek.com.tw> References: <9fb6be7b-95f3-6e59-c0f4-1d6c3357416d@pobox.com> <20161030.205755.1198665157526465556.davem@davemloft.net> <1f847ae0-4928-01e7-f1e7-3cbc37529961@pobox.com> <20161030.235342.134481656830778556.davem@davemloft.net> <0835B3720019904CB8F7AA43166CEEB201047353@RTITMBSV03.realtek.com.tw> <201611030159.uA31x0np004648@rtits1.realtek.com> <0835B3720019904CB8F7AA43166CEEB20104878A@RTITMBSV03.realtek.com.tw> <201611041425.uA4EPwCw018176@rtits1.realtek.com> In-Reply-To: <201611041425.uA4EPwCw018176@rtits1.realtek.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="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id uA9DANfe015763 Content-Length: 1486 Lines: 36 Mark Lord [mailto:mlord@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 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 don't think it is the issue of our hw. If it happens, windows or other OS may have problems, too. It is like the memory issue described in commit 990c9b347245("Merge branch 'r8152-fixes'"). It seems that the data in memory is not same with the one from the device. Besides, I test the raspberry pi with RTL8152. However, I don't find any checksum issue for TCP. I try to copy a large file and md5sum it through NFS. It works fine. Best Regards, Hayes