USB device debugging

[mnarasimha786@gmail.com (Narasimha M)]

I am able to see the corrupted data in rx_complete itself. What are
the possibilities for the data corruption in rx_complete. Any fixes to
resolve this. And from where the data in rx_submit generates

On Wed, May 25, 2016 at 3:41 PM, Bj?rn Mork <bjorn@mork.no> wrote:
> Narasimha M <mnarasimha786@gmail.com> writes:
>
>> Thanks for explanation. Here data is getting corrupted before it comes
>> to the usbnet itself, so after it reaches to usbnet and go through
>> network stack, it is failing in tcp checksum and packet is getting
>> dropped. Same driver is working with linux-3.10.20 but not working
>> with linux-2.6.32.Not able to find the exact function in driver which
>> sends receive packet to usbnet, not able to proceed further. Please
>> suggest some pointers to proceed further.
>
> This is no surprise.  There is no "send receive packet to usbnet".
>
> usbnet allocates a receive buffer and hands it to the USB host
> controller. This happens in rx_submit().  The host controller calls the
> rx_complete() callback when it gets data from the device.  This callback
> will trigger further handling in the usbnet_bh() tasklet, calling
> rx_process().  This again calls the minidriver specific rx_fixup()
> callback if there is any, which is GobiNet's only chance of inspecting
> and possibly modifying the buffer.  But normally it will not touch the
> buffer, since there is no fixup necessary for Gobi devices in 802.3 mode
> (they transmit plain ethernet packets). rx_process() ends up calling
> usbnet_skb_return() which hands the buffer over the the networking stack
> using netif_rx().
>
> So, if we ignore the possible firmware bug workarounds in rx_fixup(),
> then nothing ever touches the receive buffer in usbnet. It's just a
> handle being passed around.
>
> Note that I don't remember, or care, what 2.6.32 might have done. It's too
> outdated to be relevant.  But the usbnet design is much older and
> haven't changed drastically, so I assume most of the above is valid
> there too.
>
>
> Bj?rn



-- 
Narasimha