Hi Christoph, I've received a bug report that uas is causing a 2-disk enclosure to lookup with 4.4 and later:
https://bugzilla.redhat.com/show_bug.cgi?id=1315013 Looking at the dmesg this stands out: Mar 09 01:55:21 larry kernel: sd 2:0:0:1: [sdc] tag#31 uas_eh_abort_handler 0 uas-tag 32 inflight: CMD OUT Mar 09 01:55:21 larry kernel: sd 2:0:0:1: [sdc] tag#31 CDB: Write(10) 2a 00 e8 10 f4 00 00 04 00 00 Specifically the uas-tag 32, technically that is correct, but we have been avoiding actually submitting commands with that tag because bulk-streams are numbered 1-x and I was afraid that actually using the full-range would trigger off-by-one errors in devices and it looks I was right. Before your patch uas was doing: @@ -929,10 +928,6 @@ static int uas_probe(struct usb_interface *intf, const struct usb_device_id *id) if (result) goto set_alt0; - result = scsi_init_shared_tag_map(shost, devinfo->qdepth - 2); - if (result) - goto free_streams; - usb_set_intfdata(intf, shost); result = scsi_add_host(shost, &intf->dev); if (result) With devinfo->qdepth being 32 in this case, so the end-result would be passing 30 to scsi_init_shared_tag_map, reserving one tag for untagged commands and one tag for the off-by-one thingie. We also have: static int uas_slave_configure(struct scsi_device *sdev) { ... scsi_change_queue_depth(sdev, devinfo->qdepth - 2); ... } But that only helps with single lun enclosures, so I guess that once we fix the issue that line can actually go. So my question is how do I tell the scsi layer to not submit more then X commands with scsi_init_shared_tag_map() gone ? Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
