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