> Steve, > From memory, between SPC-2 and SPC-3 the INQUIRY allocation > length field went from 8 bits to 16 bits. If you do the > above calculation modulo 256 it comes out correct :-) > > The moral here is don't set INQUIRY lengths > 252 > unless the target can handle it. There is no point > anyway for a "standard" INQUIRY (EVPD=0, CmdDt is > obsolete). With VPD pages you can do a double fetch, > the first one 4 bytes long to pick up "page length" > field. > But then again you said the cdb was nonsense. yeah, the 2nd command was not inquiry, it is a vendor specific command. when I reduced the buffer size < 256, it began to work (not get check condition/sense key == 5). I think I just have some misunderstanding about the CDB format for xfer sizes > 256, but that is my problem, not yours. Mainly, I just thought SG_IO was behaving weird, so I thought I should mention it. It occurs to me that if I do this, below, after the SG_IO ioctl, it suppresses the extra data transferred (obviously): memset(buffer + buffer_size - sgio.resid, 0, sgio.resid); Though you mentioned that not all devices/LLD set resid? > Now it is still a bit fuzzy because there is the > allocation length field in some cdbs and the dxfer_len > given to sg_io_hdr. I would think that the LLD > should concentrate on the latter and set resid > accordingly. That makes me wonder about the LLD > involved (the sg driver just passes resid through). Hmm, I was able to get the same behavior from mptsas, qla2xxx, and cciss with SAS drives, HP MSA1000, and tape drives for target devices, respectively, so not sure the LLD matters. [...] Thanks for taking the time to explain some of this to me. I can try to distill out a small test program, if it would be of interest. -- steve - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
