Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:to:cc
        :references:from:message-id:date:mime-version:in-reply-to
        :content-type:content-transfer-encoding; q=dns; s=sasl; b=ZsrhaD
        sOqU3TPLuyEiEs6tkZ0egRypGmjAZRTKL1GhfYBk/11yPp7YeZGCJKmf8knR/NKo
        cFrYYdZ/cJjfTgOA+cRjxQYn2a8Ru4VB2FMmsDC+0MNwYP9+9BiTfTO1KSiZWD25
        8zAUV+Rqdxp1eem4ehXyWOe02k7fShyFeZtUw=
Subject: r8152: data corruption in various scenarios
To:     Ansis Atteka <aatteka@nicira.com>,
        Hayes Wang <hayeswang@realtek.com>
Cc:     David Miller <davem@davemloft.net>,
        "greg@kroah.com" <greg@kroah.com>,
        "romieu@fr.zoreil.com" <romieu@fr.zoreil.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        nic_swsd <nic_swsd@realtek.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        Kai-Heng Feng <kai.heng.feng@canonical.com>
References: <ed0c9790-57be-8bca-cdd6-3a54ca24f0bd@pobox.com>
 <20161125095350.GA20653@kroah.com>
 <1816ec7e-2733-f4ba-5d30-29dbabd20aad@pobox.com>
 <20161125.115827.2014848246966159357.davem@davemloft.net>
 <0835B3720019904CB8F7AA43166CEEB201057793@RTITMBSV03.realtek.com.tw>
 <CAA=3Oqn5_5w+vrg9_7UtZ-5BEbZ9Pm=qdX3WoVZKaAkxcMXYXA@mail.gmail.com>
From:   Mark Lord <mlord@pobox.com>
Message-ID: <469a41ea-e97c-23d2-d129-68aad5585fec@pobox.com>
Date:   Sat, 5 Jan 2019 09:14:21 -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: <CAA=3Oqn5_5w+vrg9_7UtZ-5BEbZ9Pm=qdX3WoVZKaAkxcMXYXA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-CA
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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/

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