From mboxrd@z Thu Jan 1 00:00:00 1970 From: mnarasimha786@gmail.com (Narasimha M) Date: Wed, 25 May 2016 16:21:07 +0530 Subject: USB device debugging In-Reply-To: <87a8jephuz.fsf@nemi.mork.no> References: <20160524144629.GE28161@kroah.com> <87posbqtlk.fsf@nemi.mork.no> <87a8jephuz.fsf@nemi.mork.no> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org 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 wrote: > Narasimha M 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