On Thu, 24 Jun 2010, Stanislav Brabec wrote:
> Alan Stern wrote:
> > On Thu, 24 Jun 2010, Stanislav Brabec wrote:
> >
> > > > That was the REQUEST SENSE command. It also failed; the device did not
> > > > return any sense information. This is the "incomplete SCSI frame" you
> > > > suspected. (The "short read transfer" message above occurred at this
> > > > point; the device sent 0 bytes of sense data instead of 18 bytes as it
> > > > should have.) Failure to send the sense data is clearly a bug in the
> > > > scanner.
> > >
> > > But the same scanner worked perfectly with dc395 PCI SCSI card.
> >
> > Hmm. Well then, maybe that means the scanner handles REQUEST SENSE
> > correctly and the adapter doesn't.
>
> Yes, it may be possible. But discs still work well.
To really tell what's going wrong, you would need to observe the
communication between the adapter and the scanner.
> Maybe the scanner sometimes does not respond to REQUEST SENSE or
> responds very slowly? aha152x.c had to be changed to work with this
> scanner as well. See attached patch what was needed there.
If the scanner responds too slowly for the adapter to handle, there
doesn't seem to be much you can do to fix either piece of equipment.
> Looking at the strace log with dc395 (see the first mail in the thread),
> I see many <unfinished ...> lines:
I don't know what the "<unfinished ...>" means. Regardless, strace is
the wrong tool for this problem. You need to see what's happening at
the protocol and transport levels, not at the application level.
> This appears once:
> ioctl(8, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[00, 00, 00, 00, 00, 00], mx_sb_len=64, iovec_count=0, dxfer_len=0, timeout=120000, flags=0 <unfinished ...>
> This appears many times:
> ioctl(8, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[10]=[28, 00, 00, 00, 00, 00, 00, 02, b2, 00], mx_sb_len=64, iovec_count=0, dxfer_len=690, timeout=120000, flags=0 <unfinished ...>
> After first appearance of this line, using dc395 the scan continues,
> using usbscsi everything returns ENODEV.
>
> Is it possible to provide the log similar to usbmon while using dc395
> PCI SCSI card?
Not as far as I know, but I am not an expert on Linux's SCSI stack.
You could try asking on the linux-scsi mailing list, or you could ask
the maintainer of the dc395's driver.
> > > > usb-storage treats failure of REQUEST SENSE as an error requiring a
> > > > device reset. The remainder of the usbmon log shows the reset, which
> > > > worked. But resets are always followed by TEST UNIT READY, to verify
> > > > the device's status after being reset, and the same sequence of events
> > > > repeated -- over and over again. That's why your scan didn't work.
> > >
> > > Thanks for the analysis. Is there a chance for a work-around that could
> > > be accepted to the vanilla?
> >
> > Can you think of a workaround for a failed REQUEST SENSE? I can't.
> > The sense information is absolutely vital.
>
> I was thinking about ignoring failed REQUEST SENSE and not issuing reset.
Well, you can if you want to. You will need to change the
usb_stor_invoke_transport() function in
drivers/usb/storage/transport.c. Find these lines:
/* Other failures */
if (temp_result != USB_STOR_TRANSPORT_GOOD) {
US_DEBUGP("-- auto-sense failure\n");
/* we skip the reset if this happens to be a
* multi-target device, since failure of an
* auto-sense is perfectly valid
*/
srb->result = DID_ERROR << 16;
if (!(us->fflags & US_FL_SCM_MULT_TARG))
goto Handle_Errors;
return;
}
Simply get rid of everything after the US_DEBUGP line (except the
closing '}', of course). I doubt this will work any better, but you
never know.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
