On Thu, 26 Sep 2002, Yuri Per wrote:

> 2.5.38 oopses on the last line if usb_stor_abort_transport (us->srb ==
> NULL). I attepted to fix it:
>
> --- linux-2.5.38-orig/drivers/usb/storage/transport.c    Sun Sep 22
> 08:25:06 2002
> +++ linux-2.5.38/drivers/usb/storage/transport.c    Thu Sep 26 17:18:20 2002
> @@ -859,4 +859,5 @@
>  void usb_stor_abort_transport(struct us_data *us)
>  {
> +    struct Scsi_Host *host;
>      int state = atomic_read(&us->sm_state);
>
> @@ -870,5 +871,6 @@
>      /* set state to abort and release the lock */
>      atomic_set(&us->sm_state, US_STATE_ABORTING);
> -    scsi_unlock(us->srb->host);
> +    host = us->srb->host;
> +    scsi_unlock(host);
>
>      /* If the state machine is blocked waiting for an URB or an IRQ,
> @@ -893,5 +895,5 @@
>
>      /* Reacquire the lock */
> -    scsi_lock(us->srb->host);
> +    scsi_lock(host);
>  }

Many thanks for this patch.  It fixes one of those subtle, easy-to-miss
holes in the abort logic.  I have submitted it for inclusion in the
official source tree.


> But it still does not work. insmod usb-storage takes about 20 sec. And
> just after return from insmod the whole system hangs. See log at the end
> of the letter.
>
> >> 2) If I disable command_abort by initializing eh_abort_handler to
> >> NULL, another issue occures. When scsi subsytem attempts to reset
> >> device/bus, reset fails and device is disabled. Here are log entries:
...
> I think disabling of command_abort is not correct. usb-storage can't
> perform device reset until previous request is properly aborted.

That's right.

The pattern of errors you are getting is similar to one I've seen before.
Some devices do not properly adhere to the standards, because the
designers only bother to test them under Windows.  In particular, the
firmware in some devices hangs when it receives a SCSI INQUIRE command
that asks for more than 18 bytes of information.  The first transaction in
your kernel log was an INQUIRE for 128 bytes, and that's where your
problems began.

This is an ongoing issue that has plagued many people.  Two others who
have tried to handle the problem are:
        Matthew Dharm <[EMAIL PROTECTED]>
and
        Andries Brouwer <[EMAIL PROTECTED]>
You might try asking them for suggestions on how to deal with your
difficulties.

Alan Stern





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to