scsi_free_sdev and slave destroy

scsi_free_sdev and slave destroy

[Krishna Murthy]

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



			

Re: scsi_free_sdev and slave destroy

[James Bottomley]

On Tue, 2003-11-25 at 09:07, Krishna Murthy wrote:
> 		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

scsi_scan_target and SCSI_2

[Krishna Murthy]

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

Peripheral qualifier 1 not considered in scsi_probe_and_add_lun

[Krishna Murthy]

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

Re: Peripheral qualifier 1 not considered in scsi_probe_and_add_lun

[James Bottomley]

On Thu, 2003-11-27 at 08:56, Krishna Murthy wrote:
> 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

Re: scsi_scan_target and SCSI_2

[James Bottomley]

On Thu, 2003-11-27 at 07:19, Krishna Murthy wrote:
> 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.

> 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

Re: scsi_scan_target and SCSI_2

[Krishna Murthy]

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
On Thursday 27 Nov 2003 9:07 pm, James Bottomley wrote:
> On Thu, 2003-11-27 at 07:19, Krishna Murthy wrote:
> > 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.
>
> > 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

Re: scsi_scan_target and SCSI_2

[James Bottomley]

On Thu, 2003-11-27 at 09:45, Krishna Murthy wrote:
> 	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