#5 usb protocol stall

open
Geoff Oakham
libifp (4)
7
2004-11-22
2004-11-22
Geoff Oakham
No

This bug is rare, making it more difficult to track
down. Only two people have seen it, including myself.

Symptoms:
ifp_read_data returns() -EIO and
dev->download_pipe_errors is positive

Sightings:
1. Linux, P4, moderately loaded with disk activity,
ohci controller.
2. Linux, dual AMD64.

Details:
* sending the 'DOWNLOAD' control message sometimes
returns EPIPE, which apparently means "protocol stall"
(it's _not_ a functional stall.. I've checked).
* sleep()ing for a bit and re-issuing the control
request seems to work around the problem 90% of the
time, in the kernel driver. (This trick never works in
userland.)
* if the above 'trick' doesn't work, we reach EOF
one block earlier than expected.
* timing does not seem to affect the problem.
* according to the USB spec, 'protocol stall' means
the command we sent isn't valid. (Either the command
number or the parameter values.)

Note: as of Nov 12, libifp will detect the bug and
restart the download automatically if you use
ifp_download_file() or ifp_download_dir().

Discussion