From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934173AbcKXRMH (ORCPT ); Thu, 24 Nov 2016 12:12:07 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:35496 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755951AbcKXRME (ORCPT ); Thu, 24 Nov 2016 12:12:04 -0500 Date: Thu, 24 Nov 2016 12:11:40 -0500 (EST) Message-Id: <20161124.121140.2054576632424977475.davem@davemloft.net> To: mlord@pobox.com Cc: hayeswang@realtek.com, netdev@vger.kernel.org, nic_swsd@realtek.com, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable From: David Miller In-Reply-To: <23e0c132-8844-0a34-3e0b-e412f76493ba@pobox.com> References: <0835B3720019904CB8F7AA43166CEEB201055ED8@RTITMBSV03.realtek.com.tw> <20161124.112152.692025478489876693.davem@davemloft.net> <23e0c132-8844-0a34-3e0b-e412f76493ba@pobox.com> X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 24 Nov 2016 08:12:17 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mark Lord Date: Thu, 24 Nov 2016 11:43:53 -0500 > So even if this were a platform memory coherency issue, one should > still never see ASCII data at the beginning of an rx buffer. I'm not so convinced, since this is the kind of random corruption one would expect to see when dealing with virtual caches that have aliasing or similar issues. Writes to address X that show up at address Y or not at all are precisely the signature of virtual cache aliasing problems. Is it a case of the chip writing to X but the cpu is still seeing stale data from a previous CPU store? For NFS the cpu is writing into the page cache, so we know that cpu side stores are where the ASCII text is coming from. Now is the r8152 buffer one that the USB host controller is DMA'ing into directly, or is it one that SWIOMMU or similar bounce buffering is copying into? In the latter case we are doing cpu stores into the area and the writes aren't coming from the device.