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.
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.
Looking at the strace log with dc395 (see the first mail in the thread),
I see many <unfinished ...> lines:
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?
> > > 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.
This is the patch needed for aha152x to work with this scanner:
--- aha152x.c-prepatch Fri Oct 20 23:01:30 2000
+++ aha152x.c Fri Oct 20 23:02:50 2000
@@ -2562,7 +2562,7 @@
* STCNT to trigger ENSWRAP interrupt, instead of
* polling for DFIFOFULL
*/
- the_time=jiffies + 100;
+ the_time=jiffies + 1000;
while(TESTLO(DMASTAT, DFIFOFULL|INTSTAT) && time_before(jiffies,the_time))
barrier();
@@ -2731,7 +2731,7 @@
CURRENT_SC->SCp.this_residual = CURRENT_SC->SCp.buffer->length;
}
- the_time=jiffies+100;
+ the_time=jiffies+1000;
while(TESTLO(DMASTAT, DFIFOEMP|INTSTAT) && time_before(jiffies,the_time))
barrier();
________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx
--
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
