This bug is rare, making it more difficult to track
down. Only two people have seen it, including myself.
ifp_read_data returns() -EIO and
dev->download_pipe_errors is positive
1. Linux, P4, moderately loaded with disk activity,
2. Linux, dual AMD64.
* 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
* 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().