On 12/04/2014 09:00 PM, Elliott, Robert (Server Storage) wrote: > > >> -----Original Message----- >> From: linux-scsi-owner@xxxxxxxxxxxxxxx [mailto:linux-scsi- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Hannes Reinecke >> Sent: Thursday, 04 December, 2014 10:39 AM > ... >> /** >> + * scsi_test_lun - waiting for a LUN to become ready >> + * @sdev: scsi_device to test >> + * >> + * Description: >> + * Wait for the lun associated with @sdev to become ready >> + * >> + * Send a TEST UNIT READY to detect any unit attention conditions. >> + * Retry TEST UNIT READY for up to @scsi_scan_timeout if the >> + * returned sense key is 02/04/01 (Not ready, Logical Unit is >> + * in process of becoming ready) >> + **/ >> +static int >> +scsi_test_lun(struct scsi_device *sdev) >> +{ >> + struct scsi_sense_hdr sshdr; >> + int res = SCSI_SCAN_TARGET_PRESENT; >> + int tur_result; >> + unsigned long tur_timeout = jiffies + scsi_scan_timeout * HZ; >> + >> + /* Skip for older devices */ >> + if (sdev->scsi_level <= SCSI_3) >> + return SCSI_SCAN_LUN_PRESENT; >> + >> + /* >> + * Wait for the device to become ready. >> + * >> + * Some targets take some time before the firmware is >> + * fully initialized, during which time they might not >> + * be able to fill out any REPORT_LUN command correctly. >> + * And as we're not capable of handling the >> + * INQUIRY DATA CHANGED unit attention correctly we'd >> + * rather wait here. >> + */ >> + do { >> + tur_result = scsi_test_unit_ready(sdev, SCSI_TIMEOUT, >> + 3, &sshdr); >> + if (!tur_result) { >> + res = SCSI_SCAN_LUN_PRESENT; >> + break; >> + } >> + if ((driver_byte(tur_result) & DRIVER_SENSE) && >> + scsi_sense_valid(&sshdr)) { >> + SCSI_LOG_SCAN_BUS(3, sdev_printk(KERN_INFO, sdev, >> + "scsi_scan: tur returned %02x/%02x/%02x\n", >> + sshdr.sense_key, sshdr.asc, sshdr.ascq)); >> + if (sshdr.sense_key == NOT_READY && >> + sshdr.asc == 0x04 && sshdr.ascq == 0x01) { >> + /* Logical Unit is in process >> + * of becoming ready */ >> + msleep(100); >> + continue; >> + } >> + } > > In SAS, you may see these after power on or after sending a > START STOP UNIT command with START=1, as the controller or > expander is performing staggered spinup: > 04h/11h LOGICAL UNIT NOT READY, NOTIFY (ENABLE SPINUP) REQUIRED > > Once the drive receives NOTIFY (ENABLE SPINUP), then it starts > reporting this until spinup is done: > 04h/01h LOGICAL UNIT IS IN PROCESS OF BECOMING READY > > If this function is intended for general "wait for ready" use, > then it should sit through both codes. > > If this function is only intended for drives that violate the > rule to always be capable of returning REPORT LUNS data > indicating LUN 0, it's hard to guess if 04h/11h could also > appear. > Oh, but the point is they do _NOT_ violate the rule. They follow SAM to the letter, and return a dummy LUN inventory with just LUN0. Once the firmware is ready it sets an 'REPORT LUN DATA CHANGED' UA. But the SCSI stack never acts on that UA, and the subsequent LUNs will never scanned. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 21284 (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
