On Wed, 23 Jun 2010, Stanislav Brabec wrote: > Alan Stern wrote at wed 06/16, 2010 at 17:21 -0400: > > On Wed, 16 Jun 2010, Stanislav Brabec wrote: > > > I bought an Adaptec USBXChange USB to SCSI converter, found a firmware > > > uploader patch and started to test it. > > > > > > SCSI Bernoulli disc works perfectly with the adapter but scanning on > > > UMAX Astra 1200S hangs early. > > > > > > Reading large kernel logs I suspect that scanner transfers incomplete > > > SCSI frames. They are converted to incomplete USB frames and it seems > > > that they cause switching the kernel or the device into an erroneous > > > state and never reach sane-umax using /dev/sg0 interface. The device > > > starts to respond ENODEV. > > > > > > Attaching SG_IO as they were captured with strace with USB to SCSI > > > converter and with PCI SCSI card. > > > > The strace log doesn't contain enough information. It would help to > > see a usbmon trace of the same events (see > > Documentation/usb/usbmon.txt). > > Attaching an usbmon log of this action: Started monitor, requested > preview in xsane, scanning hangs, wait few minutes, device releases > without preview done. Good. This log is very clear. > > > Tested on openSUSE's linux-2.6.31.12. > > > > > > Full kernel logs: > > > http://www.penguin.cz/~utx/temp/usbscsi-scan-logs.tar.bz2 > > > http://www.penguin.cz/~utx/temp/usbscsi-scan-logs2.tar.bz2 > > > > Those logs contain an awful lot of "Medium not present" errors, so many > > that they totally obscure the useful information. You need to suppress > > all those TEST UNIT READY commands during your test (they are probably > > meant for other devices anyway). > > Yes, I enabled USB logging into syslog, and I needed to use mouse and > keyboard for xsane. Most of the events came from mouse. usbmon shows > only relevant data. > > This seems to be relevant to the frame that causes failure: > > For example in usbscsi-scan-logs.tar.bz2, file scan.messages, line 126953 > > Mar 31 11:32:39 utx kernel: [ 908.830767] usb-storage: Status code -121; transferred 0/18 > Mar 31 11:32:39 utx kernel: [ 908.830769] usb-storage: -- short read transfer > Mar 31 11:32:39 utx kernel: [ 908.830771] usb-storage: Bulk data transfer result 0x1 > Mar 31 11:32:39 utx kernel: [ 908.830773] usb-storage: Attempting to get CSW... > Mar 31 11:32:39 utx kernel: [ 908.830775] usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Yes, that's connected to the problem. > Here is the usbmon log: And here is where the problem occurs: > ffff880110466180 2399912185 S Bo:7:004:2 -115 31 = 55534243 11000000 00000000 00000600 00000000 00000000 00000000 000000 > ffff880110466180 2399913155 C Bo:7:004:2 0 31 > > ffff880110466180 2399913170 S Bi:7:004:2 -115 13 < > ffff880110466180 2400250157 C Bi:7:004:2 0 13 = 55534253 11000000 00000000 01 The command above is TEST UNIT READY. The device replied with Check Condition status, indicating that it was not ready. Therefore usb-storage had to send a REQUEST SENSE command in order to learn what was wrong: > ffff880110466180 2400250169 S Bo:7:004:2 -115 31 = 55534243 12000000 12000000 80000603 00000012 00000000 00000000 000000 > ffff880110466180 2400252160 C Bo:7:004:2 0 31 > > ffff8800c05bc9c0 2400252177 S Bi:7:004:2 -115 18 < > ffff8800c05bc9c0 2400588162 C Bi:7:004:2 -121 0 > ffff880110466180 2400588176 S Bi:7:004:2 -115 13 < > ffff880110466180 2400589164 C Bi:7:004:2 0 13 = 55534253 12000000 12000000 01 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. 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. 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
