On Thu, 8 Nov 2012, Jason J. Herne wrote:
> 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.
It could be that the enclosure translates READ(10) and READ(16) into
different ATA commands. Maybe the big drive doesn't like the command
corresponding to READ(10).
In any case, we should strive to imitate what Windows does. If we can
figure out what that is...
My first guess would be that Windows decides based on the total number
of blocks. But it could be total capacity instead, or something else
entirely. In fact, different versions of Windows might use different
criteria.
> >> 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 don't know how the ATA layer in Linux works. You'll have to ask
someone else or figure it out yourself.
> 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.
It's not just a question of which command sd_prep_fn generates; it's
also a question of what command ultimately gets sent to the drive.
They aren't necessarily the same.
Alan Stern
--
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
