On Mon, 23 Mar 2009, Dave Mielke wrote: > [quoted lines by Alan Stern on 2009/03/23 at 09:59 -0400] > > >It could be that the device's endpoint toggle is set wrong. If that's > >the case, the problem might be fixable by doing a clear-halt before > >writing any bulk data. > > It wasn't that. The symptoms remain exactly the same. > > >If that doesn't fix the problem, there is of course a simple > >work-around: Write a 0-length message before starting your real output. > > That did it. Is it okay for the buffer address to be NULL? Yes, it is. The buffer address doesn't get used if the transfer length is 0. > What kind of problem does this action clear? It seems to be related to > operations on the device before it was last closed. usbmon shows exactly the > same operations after the open in the cases where it does and doesn't work. The only problem I know about is toggle mismatch. But you said that wasn't it. > I've found which high-level action in the prewvious use of the device seems to > trigger the problem, but, so far, I've been unable to relate it to a unique > low-level sequence of events. I'll keep searching, but, perhaps, an idea of > what a zero-length write might clear would be helpful. There's no general answer; it depends on the nature of the device. If it _were_ a toggle mismatch then the low-level sequence of events would something like: an odd number of data packets sent to the endpoint as opposed to an even number of packets. 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
