On Thu, 2016-03-31 at 17:03 +0200, Hans de Goede wrote: > Hi, > > On 31-03-16 16:48, James Bottomley wrote: > > On Thu, 2016-03-31 at 14:22 +0200, Hans de Goede wrote: > > > Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with > > > an usb-id of: 0bc2:331a, as these will fail to respond to a > > > REPORT_LUNS command. > > > > Actually, if we're sending them a report luns command, they must be > > reporting in at SCSI-3 SPC or higher. Should we be quirking them > > down to SCSI-2 instead because it reduces the risk of running into > > something else they're not doing from the SPC command set? > > These are fairly new devices, so they should really be scsi3, but the > usb <-> sata bridge (presumably) used does not seem to like > report_luns. That's what I'm questioning: REPORT LUNS is one of the big SCSI-3 changes, if they don't support that, it really looks like someone picked up an old engine and just fuzzed the inquiry data to return SCSI -3. In which case we should put it back to SCSI-2 where it belongs. Also, if it's USB<->SCSI bridge, that isn't really UAS, is it? > Note that usb-storage simple sets no_report_luns conditionally for > all usb-storage devices. The scsi people have repeatedly asked me to > not do this kinda blanket blacklisting for uas devices, because they > hope that uas will allow them to more or less do proper scsi over > usb, so we end up with blacklisting specific commands every now and > then to get devices to work. Well, we were hoping that with UAS the USB device creators would actually learn what a standard was when it bit them, yes. The fact that Seagate can release a SCSI-3 UAS device that doesn't do REPORT LUNS kind of dashes that hope. James -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html