Skip to contentSkip to conversation

SCSI & usb-storage: add try_rc_10_first flag

PATCH In review Alan Stern 3 participants 5 messages Jun 20, 2012 – Jun 23, 2012 1 message not in the archive

Subsystems (3)
SCSI USB USB mass storage driver
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alan Stern

author maintainer
#1 lore raw

PATCH 1/2 SCSI & usb-storage: add try_rc_10_first flag

Several bug reports have been received recently for USB mass-storage devices that don't handle READ CAPACITY(16) commands properly. They report bogus sizes, in some cases becoming unusable as a result.

The bugs were triggered by commit 09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI & usb-storage: add flags for VPD pages and REPORT LUNS), which caused usb-storage to stop overriding the SCSI level reported by devices. By default, the sd driver will try READ CAPACITY(16) first for any device whose level is above SCSI_SPC_2.

It seems likely that any device large enough to require the use of READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ CAPACITY(10) commands properly. Indeed, I don't know of any devices that don't handle READ CAPACITY(10) properly.

Therefore this patch (as1559) adds a new flag telling the sd driver to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag for every USB mass-storage device. If a device really is larger than 2 TB, sd will fall back to READ CAPACITY(16) just as it used to.

This fixes Bugzilla #43391.

Signed-off-by Alan Stern <[email protected]>
Acked-by Hans de Goede <[email protected]>
CC "James E.J. Bottomley" <[email protected]>
CC Matthew Dharm <[email protected]>
CC <[email protected]>

---

 drivers/scsi/sd.c              |    2 ++
 drivers/usb/storage/scsiglue.c |    6 ++++++
 include/scsi/scsi_device.h     |    1 +
 3 files changed, 9 insertions(+)
include/scsi/scsi_device.h +1 -0
Index: usb-3.4/include/scsi/scsi_device.h
===================================================================
@@ -151,6 +151,7 @@ struct scsi_device {
 					   SD_LAST_BUGGY_SECTORS */
 	unsigned no_read_disc_info:1;	/* Avoid READ_DISC_INFO cmds */
 	unsigned no_read_capacity_16:1; /* Avoid READ_CAPACITY_16 cmds */
+	unsigned try_rc_10_first:1;	/* Try READ_CAPACACITY_10 first */
 	unsigned is_visible:1;	/* is the device visible in sysfs */
 
 	DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events */
drivers/scsi/sd.c +2 -0
Index: usb-3.4/drivers/scsi/sd.c
===================================================================
@@ -1899,6 +1899,8 @@ static int sd_try_rc16_first(struct scsi
 {
 	if (sdp->host->max_cmd_len < 16)
 		return 0;
+	if (sdp->try_rc_10_first)
+		return 0;
 	if (sdp->scsi_level > SCSI_SPC_2)
 		return 1;
 	if (scsi_device_protection(sdp))
drivers/usb/storage/scsiglue.c +6 -0
Index: usb-3.4/drivers/usb/storage/scsiglue.c
===================================================================
@@ -202,6 +202,12 @@ static int slave_configure(struct scsi_d
 		if (us->fflags & US_FL_NO_READ_CAPACITY_16)
 			sdev->no_read_capacity_16 = 1;
 
+		/*
+		 * Many devices do not respond properly to READ_CAPACITY_16.
+		 * Tell the SCSI layer to try READ_CAPACITY_10 first.
+		 */
+		sdev->try_rc_10_first = 1;
+
 		/* assume SPC3 or latter devices support sense size > 18 */
 		if (sdev->scsi_level > SCSI_SPC_2)
 			us->fflags |= US_FL_SANE_SENSE;
maintainer
#2 lore raw
Quoted 21 lines · Alan Stern

Several bug reports have been received recently for USB mass-storage devices that don't handle READ CAPACITY(16) commands properly. They report bogus sizes, in some cases becoming unusable as a result.

The bugs were triggered by commit 09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI & usb-storage: add flags for VPD pages and REPORT LUNS), which caused usb-storage to stop overriding the SCSI level reported by devices. By default, the sd driver will try READ CAPACITY(16) first for any device whose level is above SCSI_SPC_2.

It seems likely that any device large enough to require the use of READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ CAPACITY(10) commands properly. Indeed, I don't know of any devices that don't handle READ CAPACITY(10) properly.

Therefore this patch (as1559) adds a new flag telling the sd driver to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag for every USB mass-storage device. If a device really is larger than 2 TB, sd will fall back to READ CAPACITY(16) just as it used to.

Quoted 7 lines

This fixes Bugzilla #43391.

Signed-off-by Alan Stern <[email protected]>
Acked-by Hans de Goede <[email protected]>
CC "James E.J. Bottomley" <[email protected]>
CC Matthew Dharm <[email protected]>
CC <[email protected]>

James, mind if I take this through my trees?

thanks,

greg k-h

maintainer
#3 lore raw
Quoted 24 lines · Greg KH
Quoted 23 lines · Alan Stern

Several bug reports have been received recently for USB mass-storage devices that don't handle READ CAPACITY(16) commands properly. They report bogus sizes, in some cases becoming unusable as a result.

The bugs were triggered by commit 09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI & usb-storage: add flags for VPD pages and REPORT LUNS), which caused usb-storage to stop overriding the SCSI level reported by devices. By default, the sd driver will try READ CAPACITY(16) first for any device whose level is above SCSI_SPC_2.

It seems likely that any device large enough to require the use of READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ CAPACITY(10) commands properly. Indeed, I don't know of any devices that don't handle READ CAPACITY(10) properly.

Therefore this patch (as1559) adds a new flag telling the sd driver to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag for every USB mass-storage device. If a device really is larger than 2 TB, sd will fall back to READ CAPACITY(16) just as it used to.

This fixes Bugzilla #43391.

Quoted 7 lines
Quoted 5 lines
Signed-off-by Alan Stern <[email protected]>
Acked-by Hans de Goede <[email protected]>
CC "James E.J. Bottomley" <[email protected]>
CC Matthew Dharm <[email protected]>
CC <[email protected]>

James, mind if I take this through my trees?

Actually, you can take 1/2 but I need to do 2/2 as a postmerge. I foresee a conflict with another patch I'm queuing that needs resolving.

Let me know when you've got 1/2 in and I'll build the postmerge tree.

Thanks,

James

maintainer
#4 lore raw
Quoted 31 lines · James Bottomley
Quoted 30 lines · Greg KH
Quoted 28 lines · Alan Stern

Several bug reports have been received recently for USB mass-storage devices that don't handle READ CAPACITY(16) commands properly. They report bogus sizes, in some cases becoming unusable as a result.

The bugs were triggered by commit 09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI & usb-storage: add flags for VPD pages and REPORT LUNS), which caused usb-storage to stop overriding the SCSI level reported by devices. By default, the sd driver will try READ CAPACITY(16) first for any device whose level is above SCSI_SPC_2.

It seems likely that any device large enough to require the use of READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ CAPACITY(10) commands properly. Indeed, I don't know of any devices that don't handle READ CAPACITY(10) properly.

Therefore this patch (as1559) adds a new flag telling the sd driver to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag for every USB mass-storage device. If a device really is larger than 2 TB, sd will fall back to READ CAPACITY(16) just as it used to.

This fixes Bugzilla #43391.

Signed-off-by Alan Stern <[email protected]>
Acked-by Hans de Goede <[email protected]>
CC "James E.J. Bottomley" <[email protected]>
CC Matthew Dharm <[email protected]>
CC <[email protected]>
Quoted 6 lines
Quoted 1 line

James, mind if I take this through my trees?

Actually, you can take 1/2 but I need to do 2/2 as a postmerge. I foresee a conflict with another patch I'm queuing that needs resolving.

Let me know when you've got 1/2 in and I'll build the postmerge tree.

Actually, forget I said this ... the postmerge has to be the other way around.

James

maintainer
#5 lore raw
Quoted 34 lines · James Bottomley
Quoted 33 lines · James Bottomley
Quoted 31 lines · Greg KH
Quoted 21 lines · Alan Stern

Several bug reports have been received recently for USB mass-storage devices that don't handle READ CAPACITY(16) commands properly. They report bogus sizes, in some cases becoming unusable as a result.

The bugs were triggered by commit 09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 (SCSI & usb-storage: add flags for VPD pages and REPORT LUNS), which caused usb-storage to stop overriding the SCSI level reported by devices. By default, the sd driver will try READ CAPACITY(16) first for any device whose level is above SCSI_SPC_2.

It seems likely that any device large enough to require the use of READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ CAPACITY(10) commands properly. Indeed, I don't know of any devices that don't handle READ CAPACITY(10) properly.

Therefore this patch (as1559) adds a new flag telling the sd driver to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag for every USB mass-storage device. If a device really is larger than 2 TB, sd will fall back to READ CAPACITY(16) just as it used to.

Quoted 7 lines

This fixes Bugzilla #43391.

Signed-off-by Alan Stern <[email protected]>
Acked-by Hans de Goede <[email protected]>
CC "James E.J. Bottomley" <[email protected]>
CC Matthew Dharm <[email protected]>
CC <[email protected]>

James, mind if I take this through my trees?

Quoted 7 lines
Quoted 4 lines

Actually, you can take 1/2 but I need to do 2/2 as a postmerge. I foresee a conflict with another patch I'm queuing that needs resolving.

Let me know when you've got 1/2 in and I'll build the postmerge tree.

Actually, forget I said this ... the postmerge has to be the other way around.

As these will probably make it to Linus before 3.5 is out, why would that be needed?

Anyway, they are in my tree now, hopefully all should be fine.

thanks,

greg k-h