From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932491AbcKINTh (ORCPT ); Wed, 9 Nov 2016 08:19:37 -0500 Received: from pb-sasl1.pobox.com ([64.147.108.66]:50020 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753364AbcKINTe (ORCPT ); Wed, 9 Nov 2016 08:19:34 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:to :references:cc:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=DTFKW6 J9Fh+7NeA+7gCCbbT+hWR6sblBeGw/lALV5Z9K6M3TwhRpQdgsgqKG7vZFt0zT4r uRDobrrLn0PvfGcR4oDf7WTstME+ZLDdwuuC9FaA/QJ1eCQo7XBz68qeTy5KA3K+ I67s0TcH50YjMnQiW9+HXr/d/1idCkL5EBYo8= Subject: Re: [PATCH net] r8152: Fix broken RX checksums. To: Hayes Wang , David Miller 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> <0835B3720019904CB8F7AA43166CEEB20104A0FD@RTITMBSV03.realtek.com.tw> Cc: nic_swsd , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" From: Mark Lord Message-ID: Date: Wed, 9 Nov 2016 08:19:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0835B3720019904CB8F7AA43166CEEB20104A0FD@RTITMBSV03.realtek.com.tw> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 26AA7A88-A67F-11E6-9AD3-92296462E9F6-82205200!pb-sasl1.pobox.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16-11-09 08:09 AM, Hayes Wang wrote: > Mark Lord [mailto:mlord@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 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. I am still doing long-term testing of various tweaks to the driver, and can now confirm that changing from kmalloc() to usb_alloc_coherent() vastly improves reliability, and re-enabling RX checksums works fine with that change. However, even with coherent URB buffers, I still see the occasional bad rx_desc: like, twice in 36 hours of continuous bashing at it. So having code in the driver to sanitize the rx_desc is essential. My current test code (shared with Hayes already) includes validation of various key fields of the rx_desc, and detects when the chip/driver/whatever gets confused. Hopefully r8152.c will get updated to take more care before trusting what it sees in the rx_desc fields. Cheers -- Mark Lord mlord@pobox.com