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

Groups > linux.kernel > #1524067 > 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 Hayes Wang <hayeswang@realtek.com> - 2016-11-17 04:40 +0100
    Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-17 15:30 +0100
    Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-17 15:40 +0100
    RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-18 09:00 +0100
      Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-18 13:10 +0100
        Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-22 14:20 +0100
        RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-23 05:00 +0100
          Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-23 14:50 +0100
            RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-23 16:20 +0100
              Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-23 20:30 +0100
                RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-24 04:30 +0100
                Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 13:40 +0100
                  RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-24 14:30 +0100
                    Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable David Miller <davem@davemloft.net> - 2016-11-24 17:30 +0100
                      Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 17:50 +0100
                        Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 18:10 +0100
                          Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable David Miller <davem@davemloft.net> - 2016-11-24 18:20 +0100
                        Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable David Miller <davem@davemloft.net> - 2016-11-24 18:20 +0100
                          Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 19:40 +0100
                            Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 19:50 +0100
                            Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <greg@kroah.com> - 2016-11-24 20:10 +0100
                              Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <greg@kroah.com> - 2016-11-24 20:20 +0100
                              Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 20:20 +0100
                                RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.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 14:40 +0100
                            Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Francois Romieu <romieu@fr.zoreil.com> - 2016-11-25 01:30 +0100
                              Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-25 04:50 +0100
                                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
                        Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH <gregkh@linuxfoundation.org> - 2016-11-24 19:50 +0100
                          Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Mark Lord <mlord@pobox.com> - 2016-11-24 20:00 +0100
                        RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-25 07:40 +0100
                          RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-25 08: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 Hayes Wang <hayeswang@realtek.com> - 2016-11-25 07:20 +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 David Miller <davem@davemloft.net> - 2016-11-24 17:30 +0100
            RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang <hayeswang@realtek.com> - 2016-11-24 13:40 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1529626

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-byte buffers, and assumes that data will
> never spill over from one such buffer to the next.
> Yet the observations here consistently show otherwise.

Wait, how do you know that data will not spill over?  What is making
that guarantee?  Will the USB device send a "zero packet" in order to
show that all of the "logical" data is now sent for this specific
endpoint?  Is there some sort of "framing" that the device does with the
USB data so that the driver "knows" where the end of packet is?

Check the zero-packet stuff for this device, that's tripped up many a
USB driver writer over the years, myself included.

thanks,

greg k-h

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

#1529638

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
> >> multiple in-kernel buffers.  A "real" URB buffer on USB2 is max 512 bytes.
> >> The driver is providing 16384-byte buffers, and assumes that data will
> >> never spill over from one such buffer to the next.
> >> Yet the observations here consistently show otherwise.
> > 
> > Wait, how do you know that data will not spill over?  What is making
> > that guarantee?  Will the USB device send a "zero packet" in order to
> > show that all of the "logical" data is now sent for this specific
> > endpoint?  Is there some sort of "framing" that the device does with the
> > USB data so that the driver "knows" where the end of packet is?
> 
> Exactly my point.
> 
> > Check the zero-packet stuff for this device, that's tripped up many a
> > USB driver writer over the years, myself included.
> 
> I haven't tripped over it myself, but only because we were careful
> to allow for such in the USB drivers I have worked on.
> 
> The r8152 driver just assumes it never happens.

Assumes what?  That the host will always consume data faster than the
device can create it?  If so, that sounds like your real problem
there...

good luck!

greg k-h

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

#1529642

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 512 bytes.
>> The driver is providing 16384-byte buffers, and assumes that data will
>> never spill over from one such buffer to the next.
>> Yet the observations here consistently show otherwise.
> 
> Wait, how do you know that data will not spill over?  What is making
> that guarantee?  Will the USB device send a "zero packet" in order to
> show that all of the "logical" data is now sent for this specific
> endpoint?  Is there some sort of "framing" that the device does with the
> USB data so that the driver "knows" where the end of packet is?

Exactly my point.

> Check the zero-packet stuff for this device, that's tripped up many a
> USB driver writer over the years, myself included.

I haven't tripped over it myself, but only because we were careful
to allow for such in the USB drivers I have worked on.

The r8152 driver just assumes it never happens.

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

#1530074

Mark Lord [mailto:mlord@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 larger transfers across
> >> multiple in-kernel buffers.  A "real" URB buffer on USB2 is max 512 bytes.
> >> The driver is providing 16384-byte buffers, and assumes that data will
> >> never spill over from one such buffer to the next.
> >> Yet the observations here consistently show otherwise.
> >
> > Wait, how do you know that data will not spill over?  What is making
> > that guarantee?  Will the USB device send a "zero packet" in order to
> > show that all of the "logical" data is now sent for this specific
> > endpoint?  Is there some sort of "framing" that the device does with the
> > USB data so that the driver "knows" where the end of packet is?
> 
> Exactly my point.
> 
> > Check the zero-packet stuff for this device, that's tripped up many a
> > USB driver writer over the years, myself included.
> 
> I haven't tripped over it myself, but only because we were careful
> to allow for such in the USB drivers I have worked on.
> 
> The r8152 driver just assumes it never happens.

What is the value of /sys/bus/usb/devices/.../power/control ?
Could you make sure it is "on" and try again?
Or you could call usb_disable_autosuspend() in probe().

Best Regards,
Hayes

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

#1530245

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 here.

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

#1529755

Mark Lord <mlord@pobox.com> :
[...]
> >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 buffer,
> and nobody else has a pointer to it other than the USB host controller,
> so there's nothing else that can write to it either.
> 
> According to the driver writer, the chip should only ever write a fresh
> rx_desc struct at the beginning of a buffer, never ASCII data.
> 
> So how does that buffer end up containing ASCII data from the NFS transfers?

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.
There could be a device or a driver problem but it may not be the real
problem.

So far the analysis focused on "how was this corrupted content written into
this receive buffer page ?". If I read David correctly (?) the "nobody
else has a pointer to it other than the USB host controller" point may be
replaced with "the pointer to it aliases some already used page".

-- 
Ueimor

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

#1529781

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 by the driver at probe time,
ten of them in all, allocated with usb_alloc_coherent() in the copy of
the driver I am testing with.

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.
-- 
Mark Lord

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

#1530078

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] | [prev] | [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] | [next] | [standalone]

#1529616

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 <hayeswang@realtek.com>
> > Date: Thu, 24 Nov 2016 13:26:55 +0000
> > 
> > > 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 here earlier just spat out this below.
> Using coherent (guarded, non-cacheable) RX buffers, with mb() calls:
> 
> [   15.199157] r8152_check_rx_desc: rx_desc looks bad.
> [   15.204270] r8152_rx_bottom: offset=0/3376 bad rx_desc
> [   15.209584] r8152_dump_rx_desc: 3d435253 3034336d 202f3a30 47524154 2f3d5445 3034336d rx_len=21075
> 
> The bad data in this case is ASCII:
> 
>         "SRC=m3400:/ TARGET=/m340"

Have you tried using usbmon?  Details for how to use it is in
Documentation/usbmon.txt and it might help you rule out the driver vs.
the USB host controller issues as it sees the raw data the USB host
controller sees before it sends it to the driver.

thanks,

greg k-h

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

#1529623

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 USB analyzer in the building though.

But it requires a MS-Windows machine (very scarce here, I don't have one)
for the incredibly user-unfriendly software.  I'm not sure if it can be
setup to stop the trace somehow at the right point either, as it takes
overnight runs usually to catch an occurrence of the issue.

I also seem to recall that it only exports data captures in a proprietary
format that only that brand of software/device can read, but perhaps
that might not be true.  Would still need to find a MS-Windows machine/license
to even check it out though.

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

#1529832

Mark Lord [mailto:mlord@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:/ TARGET=/m3400 ROOT=/
> ATTRS=nolock,addr=192.168.8.1\n"
> 
> 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.
> 
> So even if this were a platform memory coherency issue, one should still
> never see ASCII data at the beginning of an rx buffer.  The driver NEVER
> writes anything to the rx buffers.  Only the USB hardware ever does.
> 
> And only the r8152 dongle/driver exhibits this issue.
> Other USB dongles do not.  They *might* still have such issues,
> but because they use software checksums, the bad packets are caught/rejected.

Do you test it by rebooting? Maybe you could try a patch
commit 93fe9b183840 ("r8152: reset the bmu"). However, it should
only occur for the first urb buffer after rx is reset. I don't
think you would reset the rx frequently, so the situation seems
to be different.

Best Regards,
Hayes

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web