Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1530078 > unrolled thread

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <greg@kroah.com> - 2016-11-25 11:00 +0100
    Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 13:50 +0100
      Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 13:50 +0100
        Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <greg@kroah.com> - 2016-11-25 15:30 +0100
          Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 15:40 +0100
    Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 14:00 +0100
      Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <greg@kroah.com> - 2016-11-25 15:40 +0100
      Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable David Miller <davem@davemloft.net> - 2016-11-25 18:10 +0100
        RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-30 13:00 +0100
          Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-12-09 14:10 +0100

#1530078 — Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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 controller ever have pointers to the buffers.

You really are going to have to break out that USB monitor to verify
that this is the data coming across the wire.  Note, there are "cheap"
USB monitors that can be quite handy and that work on Linux:
	http://www.totalphase.com/products/beagle-usb12/

Or most high-end scopes have a USB mode that you can use to catch stuff
like this (but they are usually harder to use/trigger and only store a
very limited buffer).

good luck!

greg k-h

[toc] | [next] | [standalone]

#1530175

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.

[toc] | [prev] | [next] | [standalone]

#1530182

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.

Oh, wrong model.  That one doesn't do USB2.
The USB2 version is a mere USD$1300 in quantity.

Seems like rather a lot of money just to report a bug in a USB driver.
Perhaps the Linux Foundation might purchase one and loan it for this task?

[toc] | [prev] | [next] | [standalone]

#1530277

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/
> > 
> > USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.
> 
> Oh, wrong model.  That one doesn't do USB2.
> The USB2 version is a mere USD$1300 in quantity.
> 
> Seems like rather a lot of money just to report a bug in a USB driver.
> Perhaps the Linux Foundation might purchase one and loan it for this task?

You already have access to a USB analyzer you said, why would I try to
buy one and ship it around the world instead?  Makes no sense...

greg k-h

[toc] | [prev] | [next] | [standalone]

#1530283

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.totalphase.com/products/beagle-usb12/
>>>
>>> USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.
>>
>> Oh, wrong model.  That one doesn't do USB2.
>> The USB2 version is a mere USD$1300 in quantity.
>>
>> Seems like rather a lot of money just to report a bug in a USB driver.
>> Perhaps the Linux Foundation might purchase one and loan it for this task?
> 
> You already have access to a USB analyzer you said, why would I try to
> buy one and ship it around the world instead?  Makes no sense...

No, the company where I am consulting has a paperweight called a "USB analyzer".
It doesn't work with Linux machines.

You are the one who suggested purchase of a working Linux compatible unit,
so I was just following up to see if you were serious about that.

No worries.
I'll see if the paperweight can be converted into something useful next week.

Cheers

[toc] | [prev] | [next] | [standalone]

#1530203

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 allocation,
>> and only the driver and USB host controller ever have pointers to the buffers.
> 
> You really are going to have to break out that USB monitor to verify
> that this is the data coming across the wire.

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.

I have already spent about 50 hours looking at this issue,
and everything now points firmly at some kind of FIFO overflow
within the dongle itself.  There is no evidence to the contrary.

I am very happy to test any driver updates, or data collection mods
provided by the author, to help the author find/fix the issue.

One idea, might be to have the author try testing with the dongle
connected through a USB1.1 hub, forcing it to slower speeds.
This might make reproducing the issue (if indeed a FIFO overflow)
easier, as the host transfers will then be slower than the
ethernet wire speed.

I have access to the hardware here next Tuesday.
If we can scrounge up the USB analyzer, cables, and a suitable
MS-Windows (ugh) machine of some kind, then I'll see if it can
be programmed to somewhow capture the event.  Probably just set it
in continuous capture mode, and have the target system halt
when it sees bad data at offset zero.

This can take days to reproduce, so don't hold your breaths.

Something useful to do in the meanwhile, is to then think
about "what next" after the analyzer confirms the issue.
-- 
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com

[toc] | [prev] | [next] | [standalone]

#1530284

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 driver
> >> or kernel ever writes to those buffers after initial allocation,
> >> and only the driver and USB host controller ever have pointers to the buffers.
> > 
> > You really are going to have to break out that USB monitor to verify
> > that this is the data coming across the wire.
> 
> 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.

Broken USB host controller driver, or the device really is sending that
data to the host.  It's either one or the other, and the only way you
can rule one of them out is to look at the data on the wire.

best of luck,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1530441

From: Mark Lord <mlord@pobox.com>
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
>>> or kernel ever writes to those buffers after initial allocation,
>>> and only the driver and USB host controller ever have pointers to the buffers.
>> 
>> You really are going to have to break out that USB monitor to verify
>> that this is the data coming across the wire.
> 
> 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.

If you are the only person who can actively reproduce this, which
seems to be the case right now, this is unfortunately the only way to
reach a proper analysis and fix.

[toc] | [prev] | [next] | [standalone]

#1533253

Mark Lord <mlord@pobox.com>
[...]
> > 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.
> 
> If you are the only person who can actively reproduce this, which
> seems to be the case right now, this is unfortunately the only way to
> reach a proper analysis and fix.

I have tested it with iperf more than five days without any error.
I would think if there is any other way to reproduce it.

Best Regards,
Hayes

[toc] | [prev] | [next] | [standalone]

#1539331

On 16-12-08 10:23 PM, Hayes Wang wrote:
> Mark Lord <mlord@pobox.com>
> 
> 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 latest 4.9-rc8, and 4.8.12 kernels with the r8152 dongle yesterday,
in hope that perhaps the many EHCI fixes from those kernels might help out.

The dongle was unusable with those newer kernels.
Most of the time it failed with "Get ether addr fail\n" at startup.

On the occasions where it got past that point, it often failed
the DHCP negotiation, but this looks more like a bug elsewhere in
the kernel, possibly racing against initialization of the random
number generators.  Adding a 2-second sleep the the r8151 probe
function made this error mostly go away.

Cheers
-- 
Mark Lord

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web