On 31/07/2015 00:12, Giulio Bernardi wrote:
On 30/07/2015 23:42, Giulio Bernardi wrote:
On 27/07/2015 16:28, Alan Stern wrote:
On Mon, 27 Jul 2015, Giulio Bernardi wrote:
Sorry for the late reply, but it took me a little bit to recompile the kernel
(my laptop is slow) and I was not able to obtain any meaningful results (please
note I know nothing about kernel internals).
However, i filled scsi_sequential_lun_scan() with printk's but none of them
appeared (yes, I did echo 7 > /proc/sys/kernel/printk).
So I enabled logging for SCSI scan bus (echo 448 >
/proc/sys/dev/scsi/logging_level) and I did not see message "scsi scan:
Sequential scan\n" appearing. So I thought scsi_sequential_lun_scan() was not
being called.
That's strange. If you look at __scsi_scan_target(), you'll see that
the code calls scsi_probe_and_add_lun() for LUN 0, then it calls
scsi_report_lun_scan() (which should return 1), and then it calls
scsi_sequential_lun_scan().
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"
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.
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?
However, who should I notify about the issue? linux-scsi mailing list? bugzilla?
Thank you again for the support, I wouldn't have been able to discover this
alone.
It looks like I talked too soon. Now it scans for lun1 also, but then I have this:
kernel: scsi 6:0:0:1: scsi scan: INQUIRY pass 1 length 36
kernel: scsi 6:0:0:1: scsi scan: INQUIRY failed with code 0x40000
Giulio
Sorry, forget this last message, one of the two drives got undocked. I
reattached it and it works properly.
--
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
