Re: Multiple drives on JMS56x-based sata-usb docking station.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 30 Jul 2015, Giulio Bernardi wrote:

> > You should check that scsi_report_lun_scan() really does return 1.  If
> > it returns 0 instead (because BLIST_NOLUN is set in bflags or for any
> > other reason), that would cause the behavior you see.
> >
> 
> I found the reason of this behavior: there is BLIST_NOLUN in bflags indeed.
> It is a bug in scsi_get_device_flags_keyed():
> In fact, my device reports these strings for model and vendor:
> vendor = "Inateck                 0101"
> model = "                0101"

That's not quite right.  The vendor string is always exactly 8 bytes,
the model string is always exactly 16 bytes, and the revision string is
always exactly 4 bytes.  Therefore your device actually reports vendor
= "Inateck ", model = "                ", and revision = "0101".

> and this matches with this entry in the global scsi device list:
> {"", "Scanner", "1.80", BLIST_NOLUN}
> In fact: the check on vendor passes because strlen(devinfo->vendor) == 0 so 
> memcmp always passes, and the check on model passes because the code assumes 
> that max length of model is 16: when trimming the string (which is exactly 16 
> spaces followed by 0101) it ends up with an empty string, which then matches 
> whatever string for the same reason of the previous check.

Yes, both of those checks are buggy.  I'm surprised they weren't fixed 
long ago.

> I am recompiling the kernel now, with max = 20 instead of max = 16 to see if it 
> works, but I don't know if other devices do exist with a longer model string. 
> Maybe those limits (8 for vendor, 16 for model) were true for real scsi and not 
> for USB devices?

Those limits always hold for all SCSI devices, including USB.  They are
part of the SCSI specification.  The right way to fix this is to change
the tests, not to increase the max string length.  Does the patch below
fix the problem for you?

> However, who should I notify about the issue? linux-scsi mailing
> list? bugzilla?

If the patch works, I will submit it to the Linux SCSI maintainer.

> Thank you again for the support, I wouldn't have been able to
> discover this alone.

You're welcome.

Alan Stern



Index: usb-4.1/drivers/scsi/scsi_devinfo.c
===================================================================
--- usb-4.1.orig/drivers/scsi/scsi_devinfo.c
+++ usb-4.1/drivers/scsi/scsi_devinfo.c
@@ -592,16 +592,11 @@ int scsi_get_device_flags_keyed(struct s
 				max--;
 				vendor++;
 			}
-			/*
-			 * XXX removing the following strlen() would be
-			 * good, using it means that for a an entry not in
-			 * the list, we scan every byte of every vendor
-			 * listed in scsi_static_device_list[], and never match
-			 * a single one (and still have to compare at
-			 * least the first byte of each vendor).
-			 */
-			if (memcmp(devinfo->vendor, vendor,
-				    min(max, strlen(devinfo->vendor))))
+			/* Also skip trailing spaces */
+			while (max > 0 && vendor[max - 1] == ' ')
+				--max;
+			if (memcmp(devinfo->vendor, vendor, max) ||
+					devinfo->vendor[max])
 				continue;
 			/*
 			 * Skip spaces again.
@@ -611,8 +606,10 @@ int scsi_get_device_flags_keyed(struct s
 				max--;
 				model++;
 			}
-			if (memcmp(devinfo->model, model,
-				   min(max, strlen(devinfo->model))))
+			while (max > 0 && model[max - 1] == ' ')
+				--max;
+			if (memcmp(devinfo->model, model, max) ||
+					devinfo->model[max])
 				continue;
 			return devinfo->flags;
 		} else {

--
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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux