On Mon, Jan 05, 2009 at 11:21:57AM +0000, Martin Willms wrote: > > Just an update on our problem. > > 1.) Thanks for your answers. They helped me a lot. > > 2.) We now changed the interface between the backplane hardware (EZ USB > Controller) and Linux PC in a way, that each time no data is available on the > backplane anymore, the backplane sends zero length packets. This way the > usb_bulk_msg function never gets into timeout. I tested this a lot and I am > quiet sure, that our problem is solved now and no data gets lost anymore. > > We implemented it this way, because I got a hint from an Windows USB developer, > that aborting an USB transfer due to an timeout is not a good idea, because the > host controller operates on DMA accessible memory. He said, that this is the > standard way USB transfers are cancelled in Windows. It works fine with Linux, > too. > > This solution is OK for us. I realy did not find any problem in the way we > implemented the interface before. The only difference is, that the usb_bulk_msg > function does not get into a timeout anymore. As most of you said, this should > not be a problem, but in my application it is. > > Can it be that there still is a problem in the Linux USB implementation when > aborting transfers due to a timeout of the usb_bulk_msg function? Not that I know of, but it sounds like your application was having problems with it, not the kernel, right? thanks, greg k-h -- 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
