Re: USB Flash drive problem with 9.0

From: Alexander Motin <mav_at_FreeBSD.org>
Date: Sat, 31 Mar 2012 14:24:17 +0300
On 03/31/12 13:40, Kaho Toshikazu wrote:
> Your patch solves the problem. Thank you.

Committed to HEAD at r233746.

>> 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
Received on Sat Mar 31 2012 - 09:24:23 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC