From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D63B8C43387 for ; Sat, 5 Jan 2019 14:22:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A476E2085A for ; Sat, 5 Jan 2019 14:22:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="A+k2WjqU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726330AbfAEOWf (ORCPT ); Sat, 5 Jan 2019 09:22:35 -0500 Received: from pb-sasl20.pobox.com ([173.228.157.48]:62057 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726200AbfAEOWe (ORCPT ); Sat, 5 Jan 2019 09:22:34 -0500 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl20.pobox.com (Postfix) with ESMTP id C7EE130B39; Sat, 5 Jan 2019 09:22:32 -0500 (EST) (envelope-from mlord@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=subject:from :to:cc:references:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=ykolLrs0sXb5 T/gExCLiBe3FWJQ=; b=A+k2WjqUgBWFLcAMQ4xOZWQeeXkakV92W8wAuqJktHt+ OpCUXVijd3l+a+NZrnkWGrS8j+jqGoedLY/hVKW1YxIpTNYRzMjkoFYsPxRa6vRT eMM4MF+NGtw++Lz85z93LwgkN/oribNEvG5abPlr8TIjMNclMCUhFRC9u60w4Yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:from:to :cc:references:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=HJ4xs9 u4canwLC7W6xOy65mJOp/bllVdysBWDgeqLSSvCh/9J+HJTvnX7xR55felWteYF7 mmOpSTc/wwIXb6L92aZmJQXfoHnD4h54W3WAsnYQF9n1RcRkwjd6g5ieMYl/uoab EuKhSs0R77eNzVlMUUHrvG3DaEiz5aqkyHCtk= Received: from pb-sasl20.sea.icgroup.com (unknown [127.0.0.1]) by pb-sasl20.pobox.com (Postfix) with ESMTP id B5DEC30B38; Sat, 5 Jan 2019 09:22:32 -0500 (EST) (envelope-from mlord@pobox.com) Received: from [10.0.0.9] (unknown [24.53.240.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-sasl20.pobox.com (Postfix) with ESMTPSA id 9343430B35; Sat, 5 Jan 2019 09:22:29 -0500 (EST) (envelope-from mlord@pobox.com) Subject: Re: r8152: data corruption in various scenarios From: Mark Lord To: Ansis Atteka , Hayes Wang Cc: David Miller , "greg@kroah.com" , "romieu@fr.zoreil.com" , "netdev@vger.kernel.org" , nic_swsd , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" , Kai-Heng Feng References: <20161125095350.GA20653@kroah.com> <1816ec7e-2733-f4ba-5d30-29dbabd20aad@pobox.com> <20161125.115827.2014848246966159357.davem@davemloft.net> <0835B3720019904CB8F7AA43166CEEB201057793@RTITMBSV03.realtek.com.tw> <469a41ea-e97c-23d2-d129-68aad5585fec@pobox.com> Message-ID: <77cfa599-4bc3-3d4a-eab8-f2f102656484@pobox.com> Date: Sat, 5 Jan 2019 09:22:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <469a41ea-e97c-23d2-d129-68aad5585fec@pobox.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 55C38E08-10F5-11E9-AA9E-80D833260776-82205200!pb-sasl20.pobox.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-01-05 9:14 a.m., Mark Lord wrote: > A couple of years back, I reported data corruption resulting from > a change in kernel 3.16 which enabled hardware checksums in the r8152 driver. > This was happening on an embedded system that was using a r8152 USB dongle. > > At the time, it was very difficult to figure out what could possibly be causing it, > other than that re-enabling software checksums prevented corrupted packets from > resulting in more serious issues. > > Since that time, more and more reports of similar corruption and issues > have been trickling in. Eg. > > https://lore.kernel.org/patchwork/patch/873920/ Forgot to include this link (below) where people still have the issue even with the driver workaround. Switching to software checksums "fixes" it: https://bugzilla.redhat.com/show_bug.cgi?id=1460789 > > Note that there are reports in the thread above that the issues > are not limited to only the built-in ethernet chip of the dock. > > There is even now a special hack in the upstream r8152.c to attempt to detect > a Dell TB16 dock and disable RX Aggregation in the driver to prevent such issues. > > Well.. I have a WD15 dock, not a TB16, and that same hack also catches my dock > in its net: > > [5.794641] usb 4-1.2: Dell TB16 Dock, disable RX aggregation > > So one issue is that the code is not correctly identifying the dock, > and the WD15 is claimed to be immune from the r8152 issues. > > One of the symptoms of the r8152 issue, reported by Ansis Atteka, > were messages like this: > > xhci_hcd 0000:39:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 13 > comp_code 1 > > I just got that exact message above, with the r8152 in my 1-day old WD15 dock, > with the TB16 "workaround" enabled in Linux kernel 4.20.0. > >>>From this I conclude that the workaround is not 100% complete yet. > -- Mark Lord Real-Time Remedies Inc. mlord@pobox.com