I think there is a problem in correctly handling residuals from INQUIRY commands in tgtd using a kernel target module I'm developing for libfc. Maybe its correct in user-level transports but there may need to be a change for kernel-level transports. The length requested by the initiator can be exceeded by tgtd, but this shouldn't lead to an overrun condition for INQUIRY, as far as I can tell, but in other cases (READ commands) an overrun condition should be reported. Is this essentially correct? I can't find the wording in SPC3 or FCP4 to confirm this. Example: When an initiator sends an FCP request with INQUIRY and data length 36, tgtd gives the kernel a buffer of 66 bytes. If I set the FCP response OVERRUN flag and Residual count of 30 bytes, however, the initiator (Linux 2.6.34) retries the INQUIRY 3 times with the same data length and then gives up on LUN discovery. If I don't report the overrun, and just transfer the 36 bytes, then it works. My problem is that I don't know when to report Overrun and when not to, but the SCSI layer in tgtd should know that. My suggestion is that for INQUIRY, and perhaps some other commands (e.g., REPORT LUNS?) that tgtd (being the SCSI layer on the target) shouldn't return back a larger buffer than the target module (kernel) requested. Can we change tgtd accordingly? Another alternative would be to explicitly give the residual value and overflow/underflow indications for the response. Thanks, Joe -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
