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

[James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>]

On Wed, 2012-06-20 at 13:13 -0700, Greg KH wrote:
> On Wed, Jun 20, 2012 at 04:04:19PM -0400, Alan Stern wrote:
> > 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 <stern@xxxxxxxxxxxxxxxxxxx>
> > Acked-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> > CC: "James E.J. Bottomley" <JBottomley@xxxxxxxxxxxxx>
> > CC: Matthew Dharm <mdharm-usb@xxxxxxxxxxxxxxxxxx>
> > CC: <stable@xxxxxxxxxxxxxxx>
> 
> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html