On Wed, 12 Oct 2011, Markus Rechberger wrote: > the other tests were done with 24064*2, and fragments of 24064 which > end up to fail. > > > I guess there's some latency issue with that chipset which is only > > okay with the mentioned packet size. No -- you're changing the transfer size, not the packet size. But it's important to keep in mind that the device is completely unaware of the transfer size. All it sees are individual packets (and the time delays between them). > > I also tried to increase the packet size to 24064*2, it also causes > > corruptions (my linux kernel is patched to allow bigger sizes). If this is true then you really don't understand how the device works and there's little hope of getting to work correctly. The fact that it _usually_ works with 24064-byte transfers is just a coincidence. Maybe with further testing you can characterize the device's behavior properly. For example, does it require a certain minimum delay time between 24064-byte tranfers? What is its overall data rate (this determines the maximum delay time)? Alan Stern -- 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
