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? -- 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
