Ansis Atteka [mailto:aatt...@nicira.com]
> Sent: Tuesday, January 03, 2017 8:41 AM
[...]
> Hayes, in your iperf reproduction environment did you
> 1) connect sender and receiver directly with an Ethernet cable?
> 2) use iperf's TCP mode instead of UDP mode, because I believe that
> with UDP mode pa
On 17-01-02 07:40 PM, Ansis Atteka wrote:
..
> I think that I am getting closer to the root cause of this bug. Also,
> I have a workaround that at least makes r8152 functionally stable in
> my Dell TB15 dock. Mark, would you mind giving a chance to the patch
> that I have in the bottom of this emai
On Sat, Dec 31, 2016 at 4:07 PM, Ansis Atteka wrote:
> On Wed, Nov 30, 2016 at 3:58 AM, Hayes Wang wrote:
>> Mark Lord
>> [...]
>>> > Not sure why, because there really is no other way for the data to
>>> > appear where it does at the beginning of that URB buffer.
>>> >
>>> > This does seem a ra
On Wed, Nov 30, 2016 at 3:58 AM, Hayes Wang wrote:
> Mark Lord
> [...]
>> > Not sure why, because there really is no other way for the data to
>> > appear where it does at the beginning of that URB buffer.
>> >
>> > This does seem a rather unexpected burden to place upon someone
>> > reporting a
On 16-12-08 10:23 PM, Hayes Wang wrote:
> Mark Lord
>
> I find an issue about autosuspend, and it may result in the same
> problem with you. I don't sure if this is helpful to you, because
> it only occurs when enabling the autosuspend.
Thanks. I am using ASIX adapters now.
I did try the lates
Mark Lord
I find an issue about autosuspend, and it may result in the same
problem with you. I don't sure if this is helpful to you, because
it only occurs when enabling the autosuspend.
Best Regards,
Hayes
/*
* Copyright (c) 2014 Realtek Semiconductor Corp. All rights reserved.
*
* This pr
Mark Lord
[...]
> > Not sure why, because there really is no other way for the data to
> > appear where it does at the beginning of that URB buffer.
> >
> > This does seem a rather unexpected burden to place upon someone
> > reporting a regression in a USB network driver that corrupts user data.
>
From: Mark Lord
Date: Fri, 25 Nov 2016 07:49:35 -0500
> On 16-11-25 04:53 AM, Greg KH wrote:
>> On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote:
>>> There is no possibility for them to be used for anything other than
>>> USB receive buffers, for this driver only. Nothing in the driver
On Fri, Nov 25, 2016 at 07:49:35AM -0500, Mark Lord wrote:
> On 16-11-25 04:53 AM, Greg KH wrote:
> > On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote:
> >> There is no possibility for them to be used for anything other than
> >> USB receive buffers, for this driver only. Nothing in the d
On 16-11-25 09:22 AM, Greg KH wrote:
> On Fri, Nov 25, 2016 at 07:41:42AM -0500, Mark Lord wrote:
>> On 16-11-25 07:34 AM, Mark Lord wrote:
>>> On 16-11-25 04:53 AM, Greg KH wrote:
Note, there are "cheap" USB monitors that can be quite handy and that work
on Linux:
http://www.tot
On Fri, Nov 25, 2016 at 07:41:42AM -0500, Mark Lord wrote:
> On 16-11-25 07:34 AM, Mark Lord wrote:
> > On 16-11-25 04:53 AM, Greg KH wrote:
> >> Note, there are "cheap" USB monitors that can be quite handy and that work
> >> on Linux:
> >>http://www.totalphase.com/products/beagle-usb12/
> >
On 16-11-25 04:52 AM, Hayes Wang wrote:
..
> What is the value of /sys/bus/usb/devices/.../power/control ?
That entry does not exist -- power control is completely
disabled on this board.
Good try, though -- USB power control still causes me trouble
on PCs with mice and remote controls. But not
On 16-11-25 04:53 AM, Greg KH wrote:
> On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote:
>> There is no possibility for them to be used for anything other than
>> USB receive buffers, for this driver only. Nothing in the driver
>> or kernel ever writes to those buffers after initial alloc
On 16-11-25 04:53 AM, Greg KH wrote:
> Note, there are "cheap" USB monitors that can be quite handy and that work on
> Linux:
> http://www.totalphase.com/products/beagle-usb12/
USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.
On 16-11-25 07:34 AM, Mark Lord wrote:
> On 16-11-25 04:53 AM, Greg KH wrote:
>> Note, there are "cheap" USB monitors that can be quite handy and that work
>> on Linux:
>> http://www.totalphase.com/products/beagle-usb12/
>
> USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.
O
On 16-11-25 01:51 AM, Hayes Wang wrote:
>
> Forgive me. I provide wrong information. This is about RTL8153, not RTL8152.
No problem. Thanks for trying though.
On 16-11-25 01:11 AM, Hayes Wang wrote:
> Mark Lord [mailto:ml...@pobox.com]
..
>> If that "return 0" statement is ever executed, doesn't it result
>> in the loss/leak of a buffer?
>
> They would be found back by calling rtl_start_rx(), when the rx
> is restarted.
Good. I figured it was probably
On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote:
> There is no possibility for them to be used for anything other than
> USB receive buffers, for this driver only. Nothing in the driver
> or kernel ever writes to those buffers after initial allocation,
> and only the driver and USB host
Mark Lord [mailto:ml...@pobox.com]
> Sent: Friday, November 25, 2016 3:11 AM
[...]
> On 16-11-24 02:00 PM, Greg KH wrote:
> > On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
> >> One thought: bulk data streams are byte streams, not packets.
> >> Scheduling on the USB bus can break up la
> Mark Lord [mailto:ml...@pobox.com]
> > Sent: Friday, November 25, 2016 12:44 AM
> [...]
> > The bad data in this case is ASCII:
> >
> > "SRC=m3400:/ TARGET=/m340"
> >
> > This data is what is seen in /run/mount/utab, a file that is read/written
> > over NFS
> on
> > each boot.
> >
> >
Mark Lord [mailto:ml...@pobox.com]
> Sent: Friday, November 25, 2016 12:44 AM
[...]
> The bad data in this case is ASCII:
>
> "SRC=m3400:/ TARGET=/m340"
>
> This data is what is seen in /run/mount/utab, a file that is read/written
> over NFS on
> each boot.
>
> "SRC=m3400:/ TA
Mark Lord [mailto:ml...@pobox.com]
> Sent: Thursday, November 24, 2016 11:25 PM
[...]
> x86 has near fully-coherent memory, so it is the "easy" platform
> to get things working on. But Linux supports a very diverse number
> of platforms, with varying degrees of cache/memory coherency,
> and it can
On 16-11-24 07:27 PM, Francois Romieu wrote:
>
> Through aliasing the URB was given a page that contains said (previously)
> received file. The ethernet chip/usb host does not write anything in it.
I don't see how that could be possible. Please elaborate.
The URB buffers are statically allocated
Mark Lord :
[...]
> >From tracing through the powerpc arch code, this is the buffer that
> is being directly DMA'd into. And the USB layer does an invalidate_dcache
> on that entire buffer before initiating the DMA (confirmed via printk).
>
> The driver itself NEVER writes anything to that buffe
On Thu, Nov 24, 2016 at 02:10:36PM -0500, Mark Lord wrote:
> On 16-11-24 02:00 PM, Greg KH wrote:
> > On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
> >> One thought: bulk data streams are byte streams, not packets.
> >> Scheduling on the USB bus can break up larger transfers across
>
On 16-11-24 02:00 PM, Greg KH wrote:
> On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
>> One thought: bulk data streams are byte streams, not packets.
>> Scheduling on the USB bus can break up larger transfers across
>> multiple in-kernel buffers. A "real" URB buffer on USB2 is max 51
On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
> One thought: bulk data streams are byte streams, not packets.
> Scheduling on the USB bus can break up larger transfers across
> multiple in-kernel buffers. A "real" URB buffer on USB2 is max 512 bytes.
> The driver is providing 16384-b
On 16-11-24 01:42 PM, Greg KH wrote:
>
> Have you tried using usbmon?
This system is running rootfs over NFS, so usbmon
isn't realistically going to be usable in that scenario
without a lot of reconfiguration of the setup (which in itself
might obscure the original problem).
There is a hardware U
On 16-11-24 01:34 PM, Mark Lord wrote:
>From tracing through the powerpc arch code, this is the buffer that
> is being directly DMA'd into. And the USB layer does an invalidate_dcache
> on that entire buffer before initiating the DMA (confirmed via printk).
Slight correction: the invalidate_dcac
On Thu, Nov 24, 2016 at 11:43:53AM -0500, Mark Lord wrote:
> On 16-11-24 11:21 AM, David Miller wrote:
> > From: Hayes Wang
> > Date: Thu, 24 Nov 2016 13:26:55 +
> >
> > > I don't think the garbage results from our driver or device.
> > This is my impression with what has been presented so fa
On 16-11-24 12:11 PM, David Miller wrote:
> 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 c
From: Mark Lord
Date: Thu, 24 Nov 2016 12:00:15 -0500
> It seems I am being overly helpful here.
Either you want to cry or you want to keep helping us track down
this problem. It is your choice, and your choice alone.
Please do not pretend otherwise, everyone else in this thread is
operating w
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 vi
On 16-11-24 11:43 AM, Mark Lord wrote:
..
But how does this ASCII data end up at offset zero of the rx buffer??
Not possible -- this isn't even stale data, because only an rx_desc could
be at that offset in that buffer.
Answering my own question here, I suspect it ends up there as a result
of o
On 16-11-24 11:21 AM, David Miller wrote:
From: Hayes Wang
Date: Thu, 24 Nov 2016 13:26:55 +
I don't think the garbage results from our driver or device.
This is my impression with what has been presented so far as well.
It's not garbage.
The latest run with the debug code I posted her
From: Mark Lord
Date: Thu, 24 Nov 2016 07:31:17 -0500
> Any way we look at it though, the chip/driver are simply unreliable,
> and relying upon hardware checksums (which fail due to the driver
> looking at garbage rather than the checksum bits) leads to data
> corruption.
If the cpu/DMA implemen
From: Hayes Wang
Date: Thu, 24 Nov 2016 13:26:55 +
> I don't think the garbage results from our driver or device.
This is my impression with what has been presented so far as well.
On 16-11-24 08:26 AM, Hayes Wang wrote:
..
Besides, it doesn't seem to occur for all platforms. I have
tested the iperf more than 26 hours, and it still works fine.
I think I would get the same result on x86 or x86_64 platform.
..
x86 has near fully-coherent memory, so it is the "easy" platform
Mark Lord [mailto:ml...@pobox.com]
> Sent: Thursday, November 24, 2016 8:31 PM
[...]
> Nope. Guard zones did not fix it, so it's probably not a prefetch issue.
> Oddly, adding a couple of memory barriers to specific places in the driver
> does help, A LOT. Still not 100%, but it did pass 1800 reb
Mark Lord [mailto:ml...@pobox.com]
> Sent: Wednesday, November 23, 2016 9:41 PM
[...]
> >static void r8153_set_rx_early_size(struct r8152 *tp)
> >{
> >u32 mtu = tp->netdev->mtu;
> >u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
> >
> >ocp_write_word(tp,
On 16-11-23 02:29 PM, Mark Lord wrote:
On 16-11-23 10:12 AM, Hayes Wang wrote:
Mark Lord [ml...@pobox.com]
[...]
What does this code do:
static void r8153_set_rx_early_size(struct r8152 *tp)
{
u32 mtu = tp->netdev->mtu;
u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HL
Mark Lord [mailto:ml...@pobox.com]
> Sent: Thursday, November 24, 2016 3:30 AM
[...]
> Worth repeating: other dongles we have tried, eg. those using the asix driver,
> do not cause us any troubles here. Only the r8152 dongles do.
I couldn't tell you why you would see the problem. I have tested th
On 16-11-23 10:12 AM, Hayes Wang wrote:
Mark Lord [ml...@pobox.com]
[...]
What does this code do:
static void r8153_set_rx_early_size(struct r8152 *tp)
{
u32 mtu = tp->netdev->mtu;
u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
ocp_write_word(tp, MCU_
Mark Lord [ml...@pobox.com]
[...]
> What does this code do:
> >static void r8153_set_rx_early_size(struct r8152 *tp)
> >{
> >u32 mtu = tp->netdev->mtu;
> >u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
> >
> >ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY
What does this code do:
>static void r8153_set_rx_early_size(struct r8152 *tp)
>{
>u32 mtu = tp->netdev->mtu;
>u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
>
>ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE, ocp_data);
>}
How is ocp_data used by th
Mark Lord [mailto:ml...@pobox.com]
> Sent: Friday, November 18, 2016 8:03 PM
[..]
> How does the RTL8152 know that the limit is 16KB,
> rather than some other number? Is this a hardwired number
> in the hardware, or is it a parameter that the software
> sends to the chip during initialization?
It
On 16-11-18 07:03 AM, Mark Lord wrote:
On 16-11-18 02:57 AM, Hayes Wang wrote:
..
Besides, the maximum data length which the RTL8152 would send to
the host is 16KB. That is, if the agg_buf_sz is 16KB, the host
wouldn't split it. However, you still see problems for it.
How does the RTL8152 know
On 16-11-18 02:57 AM, Hayes Wang wrote:
..
> Besides, the maximum data length which the RTL8152 would send to
> the host is 16KB. That is, if the agg_buf_sz is 16KB, the host
> wouldn't split it. However, you still see problems for it.
How does the RTL8152 know that the limit is 16KB,
rather than
Mark Lord [mailto:ml...@pobox.com]
> Sent: Thursday, November 17, 2016 9:42 PM
[...]
> What the above sample shows, is the URB transfer buffer ran out of space in
> the
> middle
> of a packet, and the hardware then tried to just continue that same packet in
> the
> next URB,
> without an rx_desc
(resending.. not sure if the original had mailer errors)
On 16-11-16 10:36 PM, Hayes Wang wrote:
> [...]
>> Fix the hw rx checksum is always enabled, and the user couldn't switch
>> it to sw rx checksum.
>>
>> Note that the RTL_VER_01 only supports sw rx checksum only. Besides,
>> the hw rx check
On 16-11-17 09:14 AM, Mark Lord wrote:
..
Using coherent buffers (non-cacheable, allocated with usb_alloc_coherent),
Note that the same behaviour also happens with the original kmalloc'd buffers.
I can get it to fail extremely regularly by simply reducing the buffer size
(agg_buf_sz) from 16K
[...]
> Fix the hw rx checksum is always enabled, and the user couldn't switch
> it to sw rx checksum.
>
> Note that the RTL_VER_01 only supports sw rx checksum only. Besides,
> the hw rx checksum for RTL_VER_02 is disabled after
> commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable
52 matches
Mail list logo
