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@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
