Hi Matt,
sorry I didn't recognize that the situation was already clear to you. It isn't to me
completely, even
today.
What about a suggestion to separate the urb->status from tsome SCSI-command-> status?
Would this help?
which other directions you want to go?
In any case, feel free to ask me to try another version, since I can reproduce the
erraneous behaviour
100% with
this device . I understand that otherwise testing of such error situations is
extremely difficult.
I may even switch to 2.5.x for testing (not for daily work), if you recommend that.
When do you think you will do the "larger overhaul"?
Regards
Christian
Matthew Dharm wrote:
> The basic problem here is that the abort isn't recognized as an abort
> because of the URB status code.
>
> In other words, it's a bug which is attributable to the error-recovery
> code in usb-storage. I'm working on a much bigger fix which overhauls the
> entire architecture, but Greg KH has indicated that it should all be tested
> in 2.5.x and then backported, which is reasonable.
>
> Matt
>
> On Thu, Apr 18, 2002 at 03:12:27PM -0700, David Brownell wrote:
> > 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]
> > >
> > >
> > >
>
> --
> Matthew Dharm Home: [EMAIL PROTECTED]
> Maintainer, Linux USB Mass Storage Driver
>
> Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed
> suction darts!
> -- Salesperson to Greg
> User Friendly, 12/30/1997
>
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature
--
Christian Mahr (privat) [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
