On 03/31/12 07:57, Kaho Toshikazu wrote:
Could you collect more information about what's exactly happens
with the device? Can you execute some camcontrol inquiry or
camcontrol readcap commands after kernel misdetected size with
"READ CAPACITY(16)"?

If yes (device is still alive), could you run these commands
(with proper device name) and send me the output files:
camcontrol cmd da0 -E -v -c "12 00 00 00 80 00" -i 128 ->  INQ.res
camcontrol cmd da0 -E -v -c "9e 10 00 00 00 00 00 00 00 00 00 00
00 20 00 00" -i 32 ->  RC16.result

usbconfig -d 0.3 dump_device_desc

ugen0.3:<Mass Storage Device JetFlash>  at usbus0, cfg=0 md=HOST spd=HIGH 
(480Mbps) pwr=ON

   bLength = 0x0012
   bDescriptorType = 0x0001
   bcdUSB = 0x0200
   bDeviceClass = 0x0000
   bDeviceSubClass = 0x0000
   bDeviceProtocol = 0x0000
   bMaxPacketSize0 = 0x0040
   idVendor = 0x8564
   idProduct = 0x1000
   bcdDevice = 0x1100
   iManufacturer = 0x0001<JetFlash>
   iProduct = 0x0002<Mass Storage Device>
   iSerialNumber = 0x0003<83CA7S8M3LD8UGSF>
   bNumConfigurations = 0x0001

-- dmesg without any quirks --
ugen0.3:<JetFlash>  at usbus0
umass0:<JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3>  on 
usbus0
da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
da0:<JetFlash Transcend 16GB 1100>  Removable Direct Access SCSI-4 device
da0: 40.000MB/s transfers
da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C)

hexdump -Cv RC16.result
00000000  00 ff 00 00 00 00 00 00  00 00 02 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020

`hexdump -Cv INQ.res`
00000000  00 80 04 02 1f 73 6d 69  4a 65 74 46 6c 61 73 68  |.....smiJetFlash|
00000010  54 72 61 6e 73 63 65 6e  64 20 31 36 47 42 20 20  |Transcend 16GB  |
00000020  31 31 30 30 00 80 02 00  00 00 00 00 00 00 00 00  |1100............|
00000030  00 00 00 00 00 00 28 00  03 01 82 06 00 3f 00 00  |......(......?..|
00000040  00 00 28 32 00 00 00 00  00 00 00 50 50 00 00 00  |..(2.......PP...|
00000050  30 50 50 00 00 00 00 00  00 00 00 21 84 84 21 1e  |0PP........!..!.|
00000060  00 03 48 00 00 c0 00 00  00 00 00 00 00 00 00 00  |..H..@..........|
00000070  00 00 00 00 00 00 01 00  24 15 01 09 00 00 00 00  |........$.......|
00000080

-- dmesg with UQ_MSC_NO_INQUIRY --
ugen0.3:<JetFlash>  at usbus0
umass0:<JetFlash Mass Storage Device, class 0/0, rev 2.00/11.00, addr 3>  on 
usbus0
da0 at umass-sim0 bus 0 scbus11 target 0 lun 0
da0:<   >  Removable Direct Access SCSI-2 device
da0: 40.000MB/s transfers
da0: 15477MB (31696896 512 byte sectors: 255H 63S/T 1973C)


   Hmm, "READ CAPACITY(16)" can be used and device is alive.
With UQ_MSC_NO_INQUIRY, after run camcontrol, dd can read normally.
Without UQ_MSC_NO_INQUIRY, camcontrol can return something,
but dd can not be usable.

Thank you.

I see number of inconsistencies there. Device reports support for SPC-2 spec, but has PROTECT bit set in INQUIRY data, which is defined only since SPC-3 and reserved in SPC-2. Protection information, same as READ CAPACITY(16) command, defined only from SPC-3. SPC-2 devices should not know about it, returning error, but this device doesn't return error, instead returning something strange (correct sector size, but wrong number of sectors).

I see the only clean solution in following specs more closely and not checking PROTECT bit for pre-SPC-3 devices. I don't know why Linux does for all SCSI-3/SPC devices, but for this device result is fatal.

Please try the following patch. It should disable use of READ CAPACITY(16) in your case.

--- scsi_da.c   (revision 233697)
+++ scsi_da.c   (working copy)
@@ -1631,9 +1631,7 @@
                softc->minimum_cmd_size = 16;

        /* Predict whether device may support READ CAPACITY(16). */
-       if (SID_ANSI_REV(&cgd->inq_data) >= SCSI_REV_SPC3 ||
-           (SID_ANSI_REV(&cgd->inq_data) >= SCSI_REV_SPC &&
-            (cgd->inq_data.spc3_flags & SPC3_SID_PROTECT))) {
+       if (SID_ANSI_REV(&cgd->inq_data) >= SCSI_REV_SPC3) {
                softc->flags |= DA_FLAG_CAN_RC16;
                softc->state = DA_STATE_PROBE2;
        }


--
Alexander Motin
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to