Skip to contentSkip to conversation

scsi_free_sdev and slave destroy

DISCUSSION Krishna Murthy 2 participants 8 messages Nov 25, 2003 – Nov 27, 2003 SCSI

lore
Share & tools
lore
#0 lore raw

Hi,
I was going through the function
scsi_probe_and_add_lun().
It does
scsi_alloc_sdev
probe for the lun
If lun does not exist call scsi_free_sdev.

scsi_alloc_sdev calls slave_alloc of the HBA driver where as scsi_free_sdev does not seem to call slave_destroy. Please let me know if this is a bug or I am missing something.

Thanx
N.C.Krishna Murthy

#1 lore raw
Quoted 7 lines · Krishna Murthy

scsi_alloc_sdev
probe for the lun
If lun does not exist call scsi_free_sdev.

scsi_alloc_sdev calls slave_alloc of the HBA driver where as scsi_free_sdev does not seem to call slave_destroy. Please let me know if this is a bug or I am missing something.

This is a current bug and is fixed in the latest scsi patch set.

James

#2 lore raw

scsi_scan_target and SCSI_2

Hi,

scsi_probe_lun() does find out whether a target is SCSI_2 or SCSI_3. The follg is the code from the function which does that.

-------------------------------------------

sdev->scsi_level = inq_result[2] & 0x07;
        if (sdev->scsi_level >= 2 ||
            (sdev->scsi_level == 1 && (inq_result[3] & 0x0f) == 1))
                sdev->scsi_level++;

---------------------------------------------
Looks like this information is not preserved long enough to be used properly in case LUN 0 is offline.

The follg is the call sequence

scsi_scan_host_selected()

	|
scsi_scan_channel()
	|

scsi_scan_target() ->

			res = scsi_probe_and_add_lun ( lun 0)
			if res == SCSI_SCAN_TARGET_PRESENT
				scsi_sequential_lun_scan

scsi_probe_and_add_lun() calls scsi_probe_lun(). In case there is no lun 0 then the information about scsi_level is lost.
----------------------------------------------------------------------
/*
* result contains valid SCSI INQUIRY data.
*/
if ((result[0] >> 5) == 3) {
/*
* For a Peripheral qualifier 3 (011b), the SCSI
* spec says: The device server is not capable of
* supporting a physical device on this logical
* unit.
*
* For disks, this implies that there is no
* logical disk configured at sdev->lun, but there
* is a target id responding.
*/
SCSI_LOG_SCAN_BUS(3, printk(KERN_INFO
"scsi scan: peripheral qualifier of
3,"

                                        " no device added\n"));
                res = SCSI_SCAN_TARGET_PRESENT;
                goto out_free_result;
        }

------------------------------------------------------------------------------
We now call scsi_sequential_lun_scan() with BLIST_SPARSELUN,SCSI_2 as parameters, which instead should have been bflags,scsi_level as determined by scsi_probe_lun.

Isn't this is a bug? Please let me know if I am missing something.

Thanx
N.C.Krishna Murthy

#3 lore raw

Peripheral qualifier 1 not considered in scsi_probe_and_add_lun

Hi,
In scsi_probe_and_add_lun we check for Peripheral qualifier 3 (011b).
----------------------------------------------------------------------
/*
* result contains valid SCSI INQUIRY data.
*/
if ((result[0] >> 5) == 3) {
/*
* For a Peripheral qualifier 3 (011b), the SCSI
* spec says: The device server is not capable of
* supporting a physical device on this logical
* unit.
*
* For disks, this implies that there is no
* logical disk configured at sdev->lun, but there
* is a target id responding.
*/
SCSI_LOG_SCAN_BUS(3, printk(KERN_INFO
"scsi scan: peripheral qualifier of
3,"

                                        " no device added\n"));
                res = SCSI_SCAN_TARGET_PRESENT;
                goto out_free_result;
        }

------------------------------------------------------------------------------
Shouldn't the same apply for peripheral qualifier 1. This is what the SCSI spec has to say about 1:
The device server is capable of supporting specified peripheral device type on this logical unit. However the physical device is currently not connected to this logical unit.

Thanx
N.C.Krishna Murthy

#4 lore raw

Re: Peripheral qualifier 1 not considered in scsi_probe_and_add_lun

Quoted 5 lines · Krishna Murthy

Shouldn't the same apply for peripheral qualifier 1. This is what the SCSI spec has to say about 1:
The device server is capable of supporting specified peripheral device type on this logical unit. However the physical device is currently not connected to this logical unit.

We handle PQ 1 later, because it indicates a transient connection condition. See scsi_add_lun().

James

#5 lore raw

Re: scsi_scan_target and SCSI_2

In reply to Krishna Murthy
Quoted 2 lines · Krishna Murthy

scsi_probe_and_add_lun() calls scsi_probe_lun(). In case there is no lun 0 then the information about scsi_level is lost.

SAM-3 in section 4.9.2 begins "All SCSI devices shall accept LUN 0 as a valid address...".

This requirement is in SCSI-2 as well.

If your implementation doesn't do this, I suggest you fix it.

If lun 0 responds (as it is required by the standards to do), but shows only a perfunctory standards conforming response indicating it's not really present, we scan, and the scsi_level will be recorded for each correctly scanned lun.

Quoted 5 lines

We now call scsi_sequential_lun_scan() with BLIST_SPARSELUN,SCSI_2 as parameters, which instead should have been bflags,scsi_level as determined by scsi_probe_lun.

Isn't this is a bug? Please let me know if I am missing something.

No, it's deliberate. Whether we should do this is open to debate, but there's a comment in the code explaining the logic:

/*
* There's a target here, but lun 0 is offline so we
* can't use the report_lun scan. Fall back to a
* sequential lun scan with a bflags of SPARSELUN and
* a default scsi level of SCSI_2
*/

James

#6 lore raw

Re: scsi_scan_target and SCSI_2

Hi,
What I intended to say was in case we get 3 as the peripheral qualifier
in response to inquiry on lun 0, shouldn't we use the scsi level as returned in inquiry response instead of using a a default scsi level of SCSI_2.

Thanx
N.C.Krishna Murthy

Quoted 33 lines · James Bottomley
Quoted 2 lines · Krishna Murthy

scsi_probe_and_add_lun() calls scsi_probe_lun(). In case there is no lun 0 then the information about scsi_level is lost.

SAM-3 in section 4.9.2 begins "All SCSI devices shall accept LUN 0 as a valid address...".

This requirement is in SCSI-2 as well.

If your implementation doesn't do this, I suggest you fix it.

If lun 0 responds (as it is required by the standards to do), but shows only a perfunctory standards conforming response indicating it's not really present, we scan, and the scsi_level will be recorded for each correctly scanned lun.

Quoted 5 lines

We now call scsi_sequential_lun_scan() with BLIST_SPARSELUN,SCSI_2 as parameters, which instead should have been bflags,scsi_level as determined by scsi_probe_lun.

Isn't this is a bug? Please let me know if I am missing something.

No, it's deliberate. Whether we should do this is open to debate, but there's a comment in the code explaining the logic:

/*
* There's a target here, but lun 0 is offline so we
* can't use the report_lun scan. Fall back to a
* sequential lun scan with a bflags of SPARSELUN and
* a default scsi level of SCSI_2
*/

James

#7 lore raw

Re: scsi_scan_target and SCSI_2

Quoted 3 lines · Krishna Murthy

What I intended to say was in case we get 3 as the peripheral qualifier
in response to inquiry on lun 0, shouldn't we use the scsi level as returned in inquiry response instead of using a a default scsi level of SCSI_2.

It's open to debate whether a device reporting PQ 3 is required to fill in all the rest of the inquiry data correctly. The code takes the most conservative view.

James