On Wed, 7 Nov 2012, Jason J. Herne wrote:
>>> Most likely that's the answer. Of course, for a device to recognize
>>> READ(16) but not READ(10) is a violation of the SCSI spec.
>>>
I can confirm that the use of READ(10) instead of READ(16) is indeed
the problem here.
I hacked in some code that forces a READ(16) for all usb-storage
devices and the 3TB
drive's partitions were read and even auto-mounted. I did not try any writes.
>> I've not had enough time to properly find where/how to fix/hack this
>> into the code.
> It won't be simple. The current algorithm has been working for a long
> time, so people won't want to change it.
How about a new bit in struct scsi_device, read10_invalid perhaps?
An indicator that the device doesn't work with READ(10)? We can set
or not set the device at probe time based on vedor/device ids.
In sd_prep_fn this:
} else if (block > 0xffffffff) {
becomes:
} else if (block > 0xffffffff || SCpnt->device->read10_invalid) {
Although I'm not sure if we should be enabling this bit based on the
controller in
use in the enclosure, or the drive, or the combination?
READ(10) worked with the enclosure & 1.5 TB drive.
READ(10) failed with the enclosure & 3 TB drive.
3 TB drive works connected to Sata port (not sure if it is using
READ(10) or READ(16)).
I know we get to sd_prep_fn even when the drive in connected directly
via Sata, just not
sure which READ is used. I could find this out with a simple test.
--
- Jason J. Herne (hernejj@xxxxxxxxx)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
