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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
