On Tue, 5 Oct 2004, Geoff Oakham wrote: > > > It's not an endpoint stall (clear_halt() fails). > > > > What do you mean by that? I don't think there's any way to get -EPIPE > > other than by receiving a STALL token. And what do you mean, clear_halt() > > fails? In what way does it fail? (Not that there's generally much point > > in doing clear_halt() for endpoint 0.) > > After the control message returns -EPIPE, I've tried recovering by > calling usb_clear_halt() but that also returns -EPIPE. I gather from the > USB and kernel documentation that this signals a "protocol stall".. > whatever that means.
"Protocol stall" means that a control endpoint sends a STALL token not because it is halted but because it didn't understand or couldn't carry out the command you sent. Protocol stalls don't need to be cleared; the endpoint isn't halted and it will respond normally to further messages. "Functional stall" means that the endpoint really is halted, because of some error condition. It won't send or receive data until the halt is cleared. The USB spec makes an exception for functional stalls of endpoint 0; even when halted it's supposed to accept a few simple commands, including Clear Feature(halt) -- otherwise there would be no way to recover! But the spec also recommends that devices never do a functional stall on endpoint 0. > > > 90% of the time, I can > > > work around by re-issuing the request (once). But the other 10% of the > > > time, *both* requests succeed--even the original one that returned > > > -EPIPE. > > > > How do you know the request succeeded? What _was_ the request anyway? > > Good question: I know because I've pulled my hair out trying to debug it. ;) > > The request is "please send me the next x bytes of data". Normally, you > would issue a bulk transfer immediately after the control message to > fetch the actual data. If you don't, it just skips those x bytes. > > You can tell when two requests succeeded because "end of file" arrives > early, and the downloaded file is completely missing a block. Could it be that the timing of your commands isn't suitable for the device? If it gets another "send next data block" command too soon or too late after the last one, it may not be ready so it replies instead with a STALL. And maybe sometimes when it does that, it does prepare the next block of data anyhow. > I don't know enough about the usb subsystem to speculate.. but a busy > disk would keep the system bus and interrupt controller busy. Could > that be it? Something like that definitely could affect timing. It's unlikely to have any other effects though, and not on the contents of the data packets. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
