On 04/04/2013 07:12 PM, KY Srinivasan wrote: > > >> -----Original Message----- >> From: James Bottomley [mailto:jbottomley@xxxxxxxxxxxxx] >> Sent: Thursday, April 04, 2013 11:15 AM >> To: KY Srinivasan >> Cc: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; >> devel@xxxxxxxxxxxxxxxxxxxxxx; ohering@xxxxxxxx; hch@xxxxxxxxxxxxx; linux- >> scsi@xxxxxxxxxxxxxxx >> Subject: Re: scanning for LUNs >> >> On Thu, 2013-04-04 at 08:12 -0700, K. Y. Srinivasan wrote: >>> 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. >> >> Why don't you describe the problem. We can't scan randomly a bunch of >> LUNs hoping for a response (the space is 10^19). SAM thinks you use >> LUNW for this, but that's not well supported. We can't annoy USB >> devices by probing with REPORT LUNS, so conventionally most arrays >> return something for LUN0 even if they don't actually have one (That's >> what the peripheral qualifier codes are supposed to be about). We >> translate PQ1 and PQ2 to SCSI_SCAN_TARGET_PRESENT, which means no LUN, >> but there is a target to scan here. >> >> If you're sending back an error to an INQUIRY to LUN0, then you're out >> of spec. The SCSI standards say: >> >> SPC3 6.4.1: In response to an INQUIRY command received by an >> incorrect logical unit, the SCSI target device shall return the >> INQUIRY data with the peripheral qualifier set to the value >> defined in 6.4.2. The INQUIRY command shall return CHECK >> CONDITION status only when the device server is unable to return >> the requested INQUIRY data > > Thanks James. I will further investigate the issue on our platform. > Or check if you can use W_LUN for scanning. I've done a patchset for this (check the mailing list). Using W_LUN is precisely for this type of setup. (And would provide me with another scenario for using W_LUNs :-) Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
