On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote:
> The SCSI code has no means of knowing the actual length transferred,
> so has no choice but to believe the length byte in the reply.
> But the USB code does the transferring itself, and knows precisely
> how many bytes were transferred. If 36 bytes were transferred and
> the additional length byte is 0, indicating a length of 5, then the
> USB code can fix the response and change the additional length byte
> to 31, indicating a length of 36. That way the SCSI code knows that
> not 5 but 36 bytes are valid, and it gets actual vendor and model strings.
This looks related to something i also bumped into;
scsi scan: host 2 channel 0 id 0 lun 0 identifier too long, length 60, max
50. Device might be improperly identified.
The 'HBA' is idescsi with a memorex cdrw with an inquiry returning a
length value of 34
scsi_check_fill_deviceid:
...
if (scsi_check_id_size(sdev, 26 + id_page[3]))
I wrote up an ugly hack to truncate the length in idescsi_transform_pc2,
but i don't know SCSI and it doesn't seem right.
> [the code I showed does the right things; will submit actual diffs
> sooner or later]
Thanks,
Zwane
--
function.linuxpower.ca
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel