How to handle Scan for hardware changes in SCSI miniport

Hi All,

When from the Device Manager if we do scan for hardware changes what SRB
function is sent to miniport driver?

Thanks,
Shakeel.

SRB_FUNCTION_EXECUTE_SCSI.

You may see REPORT LUNS + INQUIRY to LUN 0 (order varies by port
driver/settings/whether LUN 0 is present) and then you will see INQUIRY
commands aimed at the individual LUNs. If we get back REPORT LUNS data,
the subsequent INQUIRYs are targeted at the specific LUNs although
SCSIport has been shown to scan lun 0-7 regardless.

Check http://support.microsoft.com/default.aspx?scid=kb;en-us;310072 for
more specifics. (it’s mostly correct)

Is that what you are asking or did I miss the true question?

Jeff

-----Original Message-----
From: shakeel [mailto:xxxxx@yahoo.com]
Sent: Wednesday, June 16, 2004 6:30 PM
Subject: How to handle Scan for hardware changes in SCSI miniport

Hi All,

When from the Device Manager if we do scan for hardware changes what SRB
function is sent to miniport driver?

Thanks,
Shakeel.

Jeff,
Is there some way we can ask the port driver (scsiport) to do a
REPORTLUNS first followed by INQUIRY on the reported LUNs ?
Is it mandatory to succeed an INQUIRY to LUN 0 ? What if we just have a
LUN ‘N’ configured where N!=0 ?

-g

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Goldner
Sent: Thursday, June 17, 2004 11:10 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to handle Scan for hardware changes in SCSI
miniport

SRB_FUNCTION_EXECUTE_SCSI.

You may see REPORT LUNS + INQUIRY to LUN 0 (order varies by port
driver/settings/whether LUN 0 is present) and then you will see INQUIRY
commands aimed at the individual LUNs. If we get back REPORT LUNS data,
the subsequent INQUIRYs are targeted at the specific LUNs although
SCSIport has been shown to scan lun 0-7 regardless.

Check http://support.microsoft.com/default.aspx?scid=kb;en-us;310072 for
more specifics. (it’s mostly correct)

Is that what you are asking or did I miss the true question?

Jeff

-----Original Message-----
From: shakeel [mailto:xxxxx@yahoo.com]
Sent: Wednesday, June 16, 2004 6:30 PM
Subject: How to handle Scan for hardware changes in SCSI miniport

Hi All,

When from the Device Manager if we do scan for hardware changes what SRB
function is sent to miniport driver?

Thanks,
Shakeel.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@cisco.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

You may see a SRB_FUNCTION_EXECUTE_SCSI SRB containing an inquiry cdb. If
you know that your configuration has changed, you should call
ScsiPortNotification with type BusChangeDetected to force the inquiries.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of shakeel
Sent: Wednesday, June 16, 2004 9:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to handle Scan for hardware changes in
SCSI miniport

Hi All,

When from the Device Manager if we do scan for hardware
changes what SRB function is sent to miniport driver?

Thanks,
Shakeel.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

It results in INQUIRY and REPORT LUNs calls, which any miniport must
handle.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“shakeel” wrote in message
news:…
> Hi All,
>
> When from the Device Manager if we do scan for hardware changes what SRB
> function is sent to miniport driver?
>
> Thanks,
> Shakeel.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> Is there some way we can ask the port driver (scsiport) to do a

REPORTLUNS first followed by INQUIRY on the reported LUNs ?

IIRC the miniport could request a rescan by ScsiPortNotification.

Is it mandatory to succeed an INQUIRY to LUN 0 ? What if we just have a
LUN ‘N’ configured where N!=0 ?

Please avoid this. This is a well-known cause of all sorts of issues.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

So what LUN should scsiport send REPORT_LUNS to if there’s no LUN 0?
Should it just pick one arbitrarily? Should it scan the LUN space on
each target looking for one that responds?

The LUN at 0 doesn’t need to be a disk, it just has to respond to
inquiry and REPORT_LUNS. You could stick your array’s processor LUN
there and scsiport will be happy.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Girish Kulkarni
(kulkis)
Sent: Wednesday, June 16, 2004 11:42 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to handle Scan for hardware changes in SCSI
miniport

Jeff,
Is there some way we can ask the port driver (scsiport) to do a
REPORTLUNS first followed by INQUIRY on the reported LUNs ?
Is it mandatory to succeed an INQUIRY to LUN 0 ? What if we just have a
LUN ‘N’ configured where N!=0 ?

-g

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Goldner
Sent: Thursday, June 17, 2004 11:10 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to handle Scan for hardware changes in SCSI
miniport

SRB_FUNCTION_EXECUTE_SCSI.

You may see REPORT LUNS + INQUIRY to LUN 0 (order varies by port
driver/settings/whether LUN 0 is present) and then you will see INQUIRY
commands aimed at the individual LUNs. If we get back REPORT LUNS data,
the subsequent INQUIRYs are targeted at the specific LUNs although
SCSIport has been shown to scan lun 0-7 regardless.

Check http://support.microsoft.com/default.aspx?scid=kb;en-us;310072 for
more specifics. (it’s mostly correct)

Is that what you are asking or did I miss the true question?

Jeff

-----Original Message-----
From: shakeel [mailto:xxxxx@yahoo.com]
Sent: Wednesday, June 16, 2004 6:30 PM
Subject: How to handle Scan for hardware changes in SCSI miniport

Hi All,

When from the Device Manager if we do scan for hardware changes what SRB
function is sent to miniport driver?

Thanks,
Shakeel.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@cisco.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

“Girish Kulkarni (kulkis)” wrote in message
news:xxxxx@ntdev…
>
> Is it mandatory to succeed an INQUIRY to LUN 0 ? What if we just
have a
> LUN ‘N’ configured where N!=0 ?

SCSI requires that LUN 0 be addressable, and that it supports the
INQUIRY, REQUEST SENSE, TEST UNIT READY, and (if the device supports
LUNs other than 0) REPORT LUNS commands.

We follow the SAM-2, SAM-3, SPC-2 & SPC-3 requirements regarding REPORT
LUNS. (No support for well know LUNs, just the default of 0)

From SPC-2, 7.19: A SCSI device that is capable of supporting a LUN
address other than zero shall support a REPORT LUNS command that is
addressed to logical unit zero.

SPC-3 (r19), 6.21: A SCSI device shall support a REPORT LUNS command
that is addressed to logical unit zero.

SAM-2 & SAM-3, 4.9.2: All SCSI devices shall accept LUN 0 as a valid
address.

This seems pretty unambiguous when you put these together. Depending on
port driver and version, you should expect to see an INQUIRY first to
LUN 0. (This is where the interpretation of the spec gets a little dicey

  • you have to respond to LUN 0 - SAM-x - but do you have to support ALL
    commands? Since INQUIRY is a mandatory command, that’s the
    interpretation we use.) It is acceptable to set the peripheral qualifier
    to 1 and if at all avoidable, LUN 0 should not be a disk unless the
    storage array is capable of assigning different LU mappings to each
    initiator. You should never, ever create a fake LUN that is a disk just
    to avoid a device installer popups - use a NULL inf.

If you just have a LUN ‘N’, and no LUN 0, nothing will work. If you have
a LUN ‘N’ and a LUN 0, and the range of LUNs is not contiguous, you can
use SpareseLuns for scsiport (only) but that will only get you LUNs 1-7,
nothing above that.

Storport holds more closely to the “letter of the law”: support LUN 0 &
INQUIRY + REPORT LUNS to it. Overrides are not possible.

-----Original Message-----
From: Peter Wieland
Sent: Thursday, June 17, 2004 6:51 AM
Subject: RE: How to handle Scan for hardware changes in SCSI miniport

So what LUN should scsiport send REPORT_LUNS to if there’s no LUN 0?
Should it just pick one arbitrarily? Should it scan the LUN space on
each target looking for one that responds?

The LUN at 0 doesn’t need to be a disk, it just has to respond to
inquiry and REPORT_LUNS. You could stick your array’s processor LUN
there and scsiport will be happy.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Girish Kulkarni
(kulkis)
Sent: Wednesday, June 16, 2004 11:42 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to handle Scan for hardware changes in SCSI
miniport

Jeff,
Is there some way we can ask the port driver (scsiport) to do a
REPORTLUNS first followed by INQUIRY on the reported LUNs ?
Is it mandatory to succeed an INQUIRY to LUN 0 ? What if we just have a
LUN ‘N’ configured where N!=0 ?

-g

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Goldner
Sent: Thursday, June 17, 2004 11:10 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to handle Scan for hardware changes in SCSI
miniport

SRB_FUNCTION_EXECUTE_SCSI.

You may see REPORT LUNS + INQUIRY to LUN 0 (order varies by port
driver/settings/whether LUN 0 is present) and then you will see INQUIRY
commands aimed at the individual LUNs. If we get back REPORT LUNS data,
the subsequent INQUIRYs are targeted at the specific LUNs although
SCSIport has been shown to scan lun 0-7 regardless.

Check http://support.microsoft.com/default.aspx?scid=kb;en-us;310072 for
more specifics. (it’s mostly correct)

Is that what you are asking or did I miss the true question?

Jeff

-----Original Message-----
From: shakeel [mailto:xxxxx@yahoo.com]
Sent: Wednesday, June 16, 2004 6:30 PM
Subject: How to handle Scan for hardware changes in SCSI miniport

Hi All,

When from the Device Manager if we do scan for hardware changes what SRB
function is sent to miniport driver?

Thanks,
Shakeel.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@cisco.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Peter,

Why doesn’t SCSIPORT do a REPORT_LUNS to LUN 0 first, just to know what all
LUNs are present? From there on, it may do an INQUIRY to only the LUNs that
are reported in response to REPORT_LUNS.

This way target needs to respond to only REPORT_LUNS on LUN 0 if it is not
present.

The problem occurs if INQUIRY comes first to non-existant LUN 0 and if that
fails, REPORT_LUNS never occurs.

STORPORT does REPORT_LUNS first to LUN 0 and if the response doesn’t list
LUN 0, we don’t see an INQUIRY to Lun 0 and it all works fine.

Problem is specific to SCSIPORT.

-Bandeep

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
So what LUN should scsiport send REPORT_LUNS to if there’s no LUN 0?
Should it just pick one arbitrarily? Should it scan the LUN space on
each target looking for one that responds?

The LUN at 0 doesn’t need to be a disk, it just has to respond to
inquiry and REPORT_LUNS. You could stick your array’s processor LUN
there and scsiport will be happy.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Girish Kulkarni
(kulkis)
Sent: Wednesday, June 16, 2004 11:42 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to handle Scan for hardware changes in SCSI
miniport

Jeff,
Is there some way we can ask the port driver (scsiport) to do a
REPORTLUNS first followed by INQUIRY on the reported LUNs ?
Is it mandatory to succeed an INQUIRY to LUN 0 ? What if we just have a
LUN ‘N’ configured where N!=0 ?

-g

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Goldner
Sent: Thursday, June 17, 2004 11:10 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to handle Scan for hardware changes in SCSI
miniport

SRB_FUNCTION_EXECUTE_SCSI.

You may see REPORT LUNS + INQUIRY to LUN 0 (order varies by port
driver/settings/whether LUN 0 is present) and then you will see INQUIRY
commands aimed at the individual LUNs. If we get back REPORT LUNS data,
the subsequent INQUIRYs are targeted at the specific LUNs although
SCSIport has been shown to scan lun 0-7 regardless.

Check http://support.microsoft.com/default.aspx?scid=kb;en-us;310072 for
more specifics. (it’s mostly correct)

Is that what you are asking or did I miss the true question?

Jeff

-----Original Message-----
From: shakeel [mailto:xxxxx@yahoo.com]
Sent: Wednesday, June 16, 2004 6:30 PM
Subject: How to handle Scan for hardware changes in SCSI miniport

Hi All,

When from the Device Manager if we do scan for hardware changes what SRB
function is sent to miniport driver?

Thanks,
Shakeel.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@cisco.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

In scsiport we had to be very careful whenever we tried adding a new
command into the sequence that is used across all devices. This
includes error recover, reset, bus enumeration, etc. You might be
amazed how easy it is to send some random device that an OEM shipped on
many, many machines into the weeds by sending it a command it’s never
seen before.

The risk of using new commands is lower in the class drivers - they’re
bound to a particular type of device, and they have all the identity
information available at the time they connect. SCSIPORT doesn’t know
if a device even supports SCSI-2 until it can look at the INQUIRY data,
which requires sending an INQUIRY command.

There are several reasons - this is just one of them. There are devices
that say they support SCSI-2 but that ignore IDENTIFY messages and still
require that you set the LUN in the CDB in order to select the right
LUN. To handle degenerate cases like that, SCSIPORT needs to know the
inquiry data for LUN 0 before it can even begin scanning beyond that.

STORPORT was built with enterprise storage solutions in mind, and was
able to make this compatibility trade-off. SCSIPORT possibly could now
but it wasn’t an option at the time.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bandeep Singh
Sent: Friday, June 18, 2004 6:23 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to handle Scan for hardware changes in SCSI
miniport

Peter,

Why doesn’t SCSIPORT do a REPORT_LUNS to LUN 0 first, just to know what
all LUNs are present? From there on, it may do an INQUIRY to only the
LUNs that are reported in response to REPORT_LUNS.

This way target needs to respond to only REPORT_LUNS on LUN 0 if it is
not present.

The problem occurs if INQUIRY comes first to non-existant LUN 0 and if
that fails, REPORT_LUNS never occurs.

STORPORT does REPORT_LUNS first to LUN 0 and if the response doesn’t
list LUN 0, we don’t see an INQUIRY to Lun 0 and it all works fine.

Problem is specific to SCSIPORT.

-Bandeep

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
So what LUN should scsiport send REPORT_LUNS to if there’s no LUN 0?
Should it just pick one arbitrarily? Should it scan the LUN space on
each target looking for one that responds?

The LUN at 0 doesn’t need to be a disk, it just has to respond to
inquiry and REPORT_LUNS. You could stick your array’s processor LUN
there and scsiport will be happy.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Girish Kulkarni
(kulkis)
Sent: Wednesday, June 16, 2004 11:42 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to handle Scan for hardware changes in SCSI
miniport

Jeff,
Is there some way we can ask the port driver (scsiport) to do a
REPORTLUNS first followed by INQUIRY on the reported LUNs ?
Is it mandatory to succeed an INQUIRY to LUN 0 ? What if we just have a
LUN ‘N’ configured where N!=0 ?

-g

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Goldner
Sent: Thursday, June 17, 2004 11:10 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to handle Scan for hardware changes in SCSI
miniport

SRB_FUNCTION_EXECUTE_SCSI.

You may see REPORT LUNS + INQUIRY to LUN 0 (order varies by port
driver/settings/whether LUN 0 is present) and then you will see INQUIRY
commands aimed at the individual LUNs. If we get back REPORT LUNS data,
the subsequent INQUIRYs are targeted at the specific LUNs although
SCSIport has been shown to scan lun 0-7 regardless.

Check http://support.microsoft.com/default.aspx?scid=kb;en-us;310072 for
more specifics. (it’s mostly correct)

Is that what you are asking or did I miss the true question?

Jeff

-----Original Message-----
From: shakeel [mailto:xxxxx@yahoo.com]
Sent: Wednesday, June 16, 2004 6:30 PM
Subject: How to handle Scan for hardware changes in SCSI miniport

Hi All,

When from the Device Manager if we do scan for hardware changes what SRB
function is sent to miniport driver?

Thanks,
Shakeel.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@cisco.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

“Bandeep Singh” wrote in message
news:xxxxx@ntdev…
>
> Why doesn’t SCSIPORT do a REPORT_LUNS to LUN 0 first, just to know
what all
> LUNs are present?

Probably because SCSI devices are not required to support REPORT
LUNS.
There is a long history of SCSI devices misbehaving when they receive
commands they don’t expect, so it is wise to avoid that happening.
The
data returned by the INQUIRY will indicate whether or not the device
supports REPORT LUNS.

All SCSI devices for use in this sort of environment have always been
required to support an INQUIRY on LUN 0, since SCSI was born.

> From there on, it may do an INQUIRY to only the LUNs that
> are reported in response to REPORT_LUNS.
>
> This way target needs to respond to only REPORT_LUNS on LUN 0 if it
is not
> present.

The device MUST support INQUIRY to LUN 0.

> The problem occurs if INQUIRY comes first to non-existant LUN 0 and
if that
> fails, REPORT_LUNS never occurs.
>
> STORPORT does REPORT_LUNS first to LUN 0 and if the response
doesn’t list
> LUN 0, we don’t see an INQUIRY to Lun 0 and it all works fine.

It is perhaps reasonable to assume that STORPORT will only be used
with more modern devices that support REPORT LUNS, or at least behave
properly if they don’t support it. It would be more elegantly in line
with the spec for it to do an INQUIRY on LUN 0 first like scsiport.

> Problem is specific to SCSIPORT.

No, the problem is specific to the device or device emulation. If it
doesn’t respond properly to an INQUIRY on LUN 0, then it isn’t a SCSI
device.

“Jeffrey Goldner” wrote in message
news:xxxxx@ntdev…
>
> We follow the SAM-2, SAM-3, SPC-2 & SPC-3 requirements regarding
REPORT
> LUNS. (No support for well know LUNs, just the default of 0)
>
> From SPC-2, 7.19: A SCSI device that is capable of supporting a LUN
> address other than zero shall support a REPORT LUNS command that is
> addressed to logical unit zero.
>
> SPC-3 (r19), 6.21: A SCSI device shall support a REPORT LUNS
command
> that is addressed to logical unit zero.
>
> SAM-2 & SAM-3, 4.9.2: All SCSI devices shall accept LUN 0 as a
valid
> address.
>
> This seems pretty unambiguous when you put these together.
Depending on
> port driver and version, you should expect to see an INQUIRY first
to
> LUN 0. (This is where the interpretation of the spec gets a little
dicey
> - you have to respond to LUN 0 - SAM-x - but do you have to support
ALL
> commands? Since INQUIRY is a mandatory command, that’s the
> interpretation we use.)

I don’t think there’s anything dicey here. The LUN is required to
support all commands that are compulsory for the device type. If
there isn’t a unit at LUN 0, then the peripheral qualifier could
be set to 3 and the device type set to 0x1f to indicate no device.
That leaves it compulsory to support INQUIRY, REQUEST SENSE, TEST
UNIT READY, and (if the device supports LUNs other than 0) REPORT
LUNS.

> It is acceptable to set the peripheral qualifier to 1

I hope it’s also acceptable to set it to 3 - that’s the value that
SCSI-3 requires it to be set to if a device isn’t supported on the
Logical Unit.

> and if at all avoidable, LUN 0 should not be a disk unless the
> storage array is capable of assigning different LU mappings to each
> initiator.

Why is that?