From: David Miller <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
Date: Thu, 24 Nov 2016 12:11:40 -0500 (EST) [thread overview]
Message-ID: <20161124.121140.2054576632424977475.davem@davemloft.net> (raw)
In-Reply-To: <23e0c132-8844-0a34-3e0b-e412f76493ba@pobox.com>
From: Mark Lord <mlord@pobox.com>
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.
next prev parent reply other threads:[~2016-11-24 17:12 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-11 7:15 [PATCH net 0/2] r8152: rx patches Hayes Wang
2016-11-11 7:15 ` [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang
2016-11-17 3:36 ` Hayes Wang
2016-11-17 14:14 ` Mark Lord
2016-11-17 14:25 ` Mark Lord
[not found] ` <d683c019-4e0f-6fe6-368c-c4fc86c72fe6@pobox.com>
2016-11-18 7:57 ` Hayes Wang
2016-11-18 12:03 ` Mark Lord
2016-11-22 13:12 ` Mark Lord
2016-11-23 3:52 ` Hayes Wang
2016-11-23 13:41 ` Mark Lord
2016-11-23 15:12 ` Hayes Wang
2016-11-23 19:29 ` Mark Lord
2016-11-24 3:24 ` Hayes Wang
2016-11-24 12:31 ` Mark Lord
2016-11-24 13:26 ` Hayes Wang
2016-11-24 15:24 ` Mark Lord
2016-11-25 6:11 ` Hayes Wang
2016-11-25 12:36 ` Mark Lord
2016-11-24 16:21 ` David Miller
2016-11-24 16:43 ` Mark Lord
2016-11-24 17:00 ` Mark Lord
2016-11-24 17:13 ` David Miller
2016-11-24 17:11 ` David Miller [this message]
2016-11-24 18:34 ` Mark Lord
2016-11-24 18:49 ` Mark Lord
2016-11-24 19:00 ` Greg KH
2016-11-24 19:10 ` Mark Lord
2016-11-24 19:17 ` Greg KH
2016-11-25 9:52 ` Hayes Wang
2016-11-25 13:32 ` Mark Lord
2016-11-25 0:27 ` Francois Romieu
2016-11-25 3:49 ` Mark Lord
2016-11-25 9:53 ` Greg KH
2016-11-25 12:34 ` Mark Lord
2016-11-25 12:41 ` Mark Lord
2016-11-25 14:22 ` Greg KH
2016-11-25 14:35 ` Mark Lord
2016-11-25 12:49 ` Mark Lord
2016-11-25 14:24 ` Greg KH
2016-11-25 16:58 ` David Miller
2016-11-30 11:58 ` Hayes Wang
2016-12-09 3:23 ` Hayes Wang
2016-12-09 13:05 ` Mark Lord
2017-01-01 0:07 ` Ansis Atteka
2017-01-03 0:40 ` Ansis Atteka
2017-01-03 13:19 ` Mark Lord
2017-01-09 7:58 ` Hayes Wang
2019-01-05 14:14 ` r8152: data corruption in various scenarios Mark Lord
2019-01-05 14:22 ` Mark Lord
2019-01-06 19:14 ` Kai Heng Feng
2019-01-06 21:13 ` Mark Lord
2019-01-06 21:16 ` Mark Lord
2019-01-07 3:53 ` Hayes Wang
2019-01-07 16:01 ` Mario.Limonciello
2019-01-07 18:06 ` Mark Lord
2019-01-07 18:27 ` Mario.Limonciello
2019-01-07 19:24 ` Mark Lord
2019-01-07 4:09 ` Kai Heng Feng
2019-01-07 4:13 ` Mark Lord
2019-01-07 6:46 ` Kai Heng Feng
2019-01-07 7:01 ` Mark Lord
2016-11-24 18:42 ` [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH
2016-11-24 18:58 ` Mark Lord
2016-11-25 6:31 ` Hayes Wang
2016-11-25 6:51 ` Hayes Wang
2016-11-25 12:35 ` Mark Lord
2016-11-24 16:19 ` David Miller
2016-11-24 12:37 ` Hayes Wang
2016-11-11 7:15 ` [PATCH net 2/2] r8152: rx descriptor check Hayes Wang
2016-11-11 12:13 ` Francois Romieu
2016-11-12 13:21 ` Mark Lord
2016-11-14 6:43 ` Hayes Wang
2016-11-15 1:10 ` Francois Romieu
2016-11-17 3:05 ` Hayes Wang
2016-11-13 17:39 ` David Miller
2016-11-13 20:34 ` Mark Lord
2016-11-13 20:38 ` Mark Lord
2016-11-14 7:23 ` Hayes Wang
2016-11-14 17:27 ` David Miller
2016-11-14 7:03 ` Hayes Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161124.121140.2054576632424977475.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=hayeswang@realtek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mlord@pobox.com \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).