Re: USB Flash drive problem with 9.0

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.._at_..........|
> 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)
_at__at_ -1631,9 +1631,7 _at__at_
                 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