[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Apr 2013 08:12:37 -0700
From: "K. Y. Srinivasan" <kys@...rosoft.com>
To: gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
devel@...uxdriverproject.org, ohering@...e.com,
jbottomley@...allels.com, hch@...radead.org,
linux-scsi@...r.kernel.org, kys@...rosoft.com
Subject: scanning for LUNs
Here is the code snippet for scanning LUNS (drivers/scsi/scsi_scan.c in function
__scsi_scan_target()):
/*
* Scan LUN 0, if there is some response, scan further. Ideally, we
* would not configure LUN 0 until all LUNs are scanned.
*/
res = scsi_probe_and_add_lun(starget, 0, &bflags, NULL, rescan, NULL);
if (res == SCSI_SCAN_LUN_PRESENT || res == SCSI_SCAN_TARGET_PRESENT) {
if (scsi_report_lun_scan(starget, bflags, rescan) != 0)
So, if we don't get a response while scanning LUN0, we will not use scsi_report_lun_scan().
On Hyper-V, the scsi emulation on the host does not treat LUN0 as anything special and we
could have situations where the only device under a scsi controller is at a location other than 0
or 1. In this case the standard LUN scanning code in Linux fails to detect this device. Is this
behaviour expected? Why is LUN0 treated differently here. Looking at the scsi spec, I am not sure
if this is what is specified. Any help/guidance will be greatly appreciated.
Regards,
K. Y
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists