I forget, didn't you verify that this problem repeated just
as cleanly using this device in USB 1.1 mode?
I'm recalling this as an issue where the usb-storage
driver needed to update its error handling, and there
was no particular "USB 2.0" issue. And at any rate
the patch is to usb-storage ...
I'm glad that with the patch, you can use another USB 2.0
device with Linux!
- Dave
> >>> Proposed workaround:
>
> set us->notify also in cases where the urb returns status DID_ERROR, not
> only DID_ABORT:
>
> patch:
>
>-----------------------------------------------------------------------------------------------
>
> --- usb.c Tue Apr 16 21:17:56 2002
> +++ usb.c-cm Tue Apr 16 21:16:56 2002
> @@ -465,7 +465,12 @@
> US_DEBUGP("scsi cmd done,
> result=0x%x\n",
> us->srb->result);
> set_current_state(TASK_INTERRUPTIBLE);
> - us->srb->scsi_done(us->srb);
> +/*05-Apr-02 cm*/
> + if (us->srb->scsi_done)
> + us->srb->scsi_done(us->srb);
> + US_DEBUGP("scsi_done() called\n");
> + if (us->srb->result == DID_ERROR <<
> 16) /* scsi_abort may wait here */
> + complete(&(us->notify));
> } else {
> US_DEBUGP("scsi command aborted\n");
> set_current_state(TASK_INTERRUPTIBLE);
>
>------------------------------------------------------------------------------------------------
>
> Any Comments?
>
> I can come around the problem with the patch, but I feel not strong
> enough to correct this problem the "proper" way.
>
> On the other hand I feel that the SCSI command abortion procedure may be
> broken anyhow when perfomed in the presence of lower layer errors
> (which may be the cause for the abortion in the first place)
>
> What shall we do?
>
> Christian
>
>
> PS: I want to keep this neat device "archos jukebox", snice this bug is
> perfectly reproducible.............
>
>
>
> --
> Christian Mahr (privat) [EMAIL PROTECTED]
>
>
>
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
