Date: Sat, 31 Mar 2012 13:16:05 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Kaho Toshikazu <vinwa@elam.kais.kyoto-u.ac.jp> Cc: freebsd-current@FreeBSD.org, day1234@hotmail.com, freebsd-usb@FreeBSD.org, Andriy Gapon <avg@FreeBSD.org>, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: USB Flash drive problem with 9.0 Message-ID: <4F76D965.80102@FreeBSD.org> In-Reply-To: <8850.1333169871@elam.kais.kyoto-u.ac.jp> References: <COL112-W354F702F0F2A3DDF718D49B7460@phx.gbl> <201203230825.32954.hselasky@c2i.net> <17628.1332555469@pf2.ed.niigata-u.ac.jp> <4F6D9672.4050201@FreeBSD.org> <2087.1332651759@pf2.ed.niigata-u.ac.jp> <4F6EF03E.6060001@FreeBSD.org> <1782.1332719733@pf2.ed.niigata-u.ac.jp> <4F75F8E5.9000508@FreeBSD.org> <8850.1333169871@elam.kais.kyoto-u.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F76D965.80102>