On Sun, 8 Jun 2003, Martin Kittel wrote:

> Hi Alan,
> 
> thanks for your quick reply.
> 
> I finally got the camera to work, although my impression is that I am
> treating the symptoms rather than curing the disease...

Sounds like it, from your description.

> It seems that the camera (Praktica Genius 1.3 using transparent SCSI and
> bulk-only transport) returns -EPIPE on every third read request(a series
> of partial reads seems to count as one read). The CSW following this
> error always has an illegal tag value which can be constructed from the
> value of the original tag (in fact it is bcb->Tag * 0x100 + 0x43) and a
> command status of 0x01. After clearing the bulk-in pipe one can proceed
> as usual.

What would happen if the original Tag were 0x43434343?  Then the illegal 
Tag value would be equal to the expected value.  Just a minor point...

> The idea to handle this problem is to recognize in
> usb_stor_Bulk_transport() that the problem has occured during a read and
> to just resend the command in that case.
> 
> To be able to do so I added an error US_BULK_TRANSFER_STALLED which is
> set if -EPIPE occurs in usb_stor_transfer_partial()
> (US_BULK_TRANSFER_SHORT would not do). In usb_stor_Bulk_transport() a
> flag is set if this error is encountered.

Such an error code already exists in Linux 2.5.  But vanilla 2.5 wouldn't 
do any better than 2.4 in trying to handle your camera!

> After reading the CSW package there are the following possibilities:
> 
> tag ok, flag not set:
>       this should be the normal case if everything worked fine
> 
> tak ok, flag set:
>       the -EPIPE in usb_stor_transfer_partial() was real, initiate normal
> error handling
> 
> tag not ok, flag not set:
>       the bug was triggered during the first attempt to get the CSW; the
> proper thing to do would probably be to resend the command, I am just
> assuming that the command would have been ok and fixing the status from
> 0x01 to 0x00
> 
> tag not ok, flag set:
>       the bug was triggered in usb_stor_transfer_partial(), resend the command
> 
> I can't really imagine that this bug can go unnoticed in a driver, so I
> imagine the driver within the camera is maybe assuming a special
> sequence of statements that prevents this bug from being triggered.
> However, I have no idea what this sequence could be...

Maybe there's a faint hope of getting in touch with the manufacturer to 
see if they can explain what's going on.  Or maybe they have updated 
firmware that will fix the problem.  It's even possible that they put 
this behavior in deliberately, so that the camera would work only with 
their proprietary drivers.

> Since I got the camera working I noticed some more odd things about it:
> - it returns only 8 bytes instead of the expected 255 on a MODE_SENSE
> command, the CSW data residue is 0 however; my impression is that it
> generally does this when sending too short an answer...

Sending only 8 rather than 255 is perfectly okay, but the CSW residue 
value should then be equal to 247.  Since we don't check the residue 
anyhow, though, it doesn't matter.

> - it seems to hang completely on a WRITE_10 command, resets do not help,
> one has to unplug it to get it going again (to avoid this, I am mounting
> it read-only)

Very nasty.  That prevents you from deleting files on the camera.

> In case you are interested, I attached a patch to illustrate what I
> actually did to get the camera working. It is merely intended for
> illustration and not even formatted properly...
> 
> Best wishes,
> 
> Martin.
> 
> BTW, the patch includes the interrupt handling changes you sent to me..
> and is against 2.4.21-rc6-vanilla

My personal feeling is that this sort of change is too error-prone to be 
adopted into the regular distribution.  But that decision is really up to 
Matt Dharm, who is the maintainer for the USB Storage device driver.  Of 
course, that shouldn't prevent you from using it in your own kernels.

Good luck.

Alan Stern



-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to