On 3/7/2013 9:47 AM, Elliott, Robert (Server Storage) wrote:
>> +int scsi_do_report_luns(struct scsi_device *sdev, int length, + * We
>> can get a UNIT ATTENTION, for example a power on/reset, so + * retry a
>> few times (like sd.c does for TEST UNIT READY). + * Experience shows
>> some combinations of adapter/devices get at + * least two power
>> on/resets. + for (retries = 0; retries < 3; retries++) { +
>> SCSI_LOG_SCAN_BUS(3, printk(KERN_INFO "scsi scan: Sending" + "
>> REPORT LUNS to %s (try %d)\n", devname, + retries)); + result =
>> scsi_execute_req(sdev, scsi_cmd, DMA_FROM_DEVICE, + lun_data,
>> length, &sshdr, + SCSI_TIMEOUT + 4 * HZ, 3, NULL);
>
> There's no guarantee that you'll get no more than two unit attention
> conditions at any particular time;
Actually, if your getting any unit attentions from a report luns the device
is broken. SAM5 5.14
"if a REPORT LUNS command enters the enabled command state, the device server
shall process the REPORTS LUNS command and shall not report any unit attention
conditions"
This is not new behavior either.
There are a couple other places that say similar things, INQUIRY and REPORT
LUNS get special status for UA. Which is how you can scan a target/lun
configuration without interfering with its operation. Personally, I think the
TUR in the mid layer is incorrect as the TUR functionality needs to be hoisted
higher up the stack and the mid layer needs to use inquiry to validate device
communications. (got a patch for that too, but no point in posting it, as it
will be ignored).
--
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
