Query Regarding PDO children enumeration

Raj_yalgar · July 24, 2013, 11:41pm

Hi Experts,
I am looking in to an iscsi lun discovery issue on windows server 2008 R2.
I am using micosoft MPIO framework and MSDSM software. One of micosoft MPIO API DsmGetAssociatedDevice() is failing to return me the PDO’s associated with port FDO. I generated a memory dump and tried to analyse the device tree and found following.

When i execute drvobj on iscsi port driver i get following

STEP 1

0: kd> !drvobj iScsiPrt
Driver object (fffffa806e295be0) is for:
\Driver\iScsiPrt
Driver Extension List: (id , addr)
(fffff88000d4c090 fffffa806e2d7810)
Device Object list:
fffffa808d59f8c0 fffffa808d5909c0 fffffa805928d9c0 fffffa808d0bb8b0 fffffa806e2e5060

fffffa806e2e5060 is a port PDO which is returned by MS MPIO framework during device discovery and is input to the MS MPIO API DsmGetAssociatedDevice() .

STEP 2

0: kd> !devobj fffffa806e2e5060
Device object (fffffa806e2e5060) is for:
RaidPort5 \Driver\iScsiPrt DriverObject fffffa806e295be0
Current Irp 00000000 RefCount 0 Type 00000004 Flags 00000050
Dacl fffff9a1000cac71 DevExt fffffa806e2e51b0 DevObjExt fffffa806e2e5b40
ExtensionFlags (0000000000)
AttachedTo (Lower) fffffa80310a54d0 \Driver\PnpManager
Device queue is not busy.

This does not give me DevNode object and i want to know how to enumerate the children associated with device object fffffa806e2e5060
However if i run same command on other device objects from step 1,we get devNode

STEP 3

0: kd> !devobj fffffa808d59f8c0
Device object (fffffa808d59f8c0) is for:
00000199 \Driver\iScsiPrt DriverObject fffffa806e295be0
Current Irp 00000000 RefCount 0 Type 00000007 Flags 00001050
Dacl fffff9a1004db700 DevExt fffffa808d59fa10 DevObjExt fffffa808d59fe90 DevNode fffffa808d6519e0
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedDevice (Upper) fffffa808d5ad9d0 \Driver\Disk
Device queue is not busy.

However devNode is listed for this device.

I have following queries

How i can list the childrens associated with port PDO fffffa806e2e5060
When i ran !devnode 0 1 i got following output , Please note fffffa806e2e5060 PDO is not listed in below output . However it was listed by WinDBG in step 1. Why it is not listed when we executed !devNode 0 1

DevNode 0xfffffa80310a5200 for PDO 0xfffffa80310a54d0
InstancePath is “Root\ISCSIPRT\0000”
ServiceName is “iScsiPrt”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xfffffa808d581d90 for PDO 0xfffffa808d0bb8b0
InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000827”
ServiceName is “disk”
State = DeviceNodeQueryRemoved (0x310)
Previous State = DeviceNodeStarted (0x308)
DevNode 0xfffffa808d582d90 for PDO 0xfffffa805928d9c0
InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000927”
ServiceName is “disk”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xfffffa808d6578a0 for PDO 0xfffffa808d5909c0
InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000027”
ServiceName is “disk”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xfffffa808d6519e0 for PDO 0xfffffa808d59f8c0
InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000127”
ServiceName is “disk”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)

thanks for your time and consideration.

Thanks,
Rajesh

OSR_Community_User · July 24, 2013, 11:58pm

What is the actual problem you’re trying to solve? Do you have a driver in the stack? My first inclination is that the MS iSCSI stack is relatively solid and I’d be surprised if there was an issue in the discovery process.

My first suggestion is to remove MPIO, and use a single iSCSI session to validate discovery. Then use a network trace to analyze the iSCSI discovery process. The device objects you are listing are below the MPIO stack and represent the PDO’s enumerated by the iSCSI port driver.

~kenny

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, July 24, 2013 8:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Query Regarding PDO children enumeration

Hi Experts,
I am looking in to an iscsi lun discovery issue on windows server 2008 R2.
I am using micosoft MPIO framework and MSDSM software. One of micosoft MPIO API DsmGetAssociatedDevice() is failing to return me the PDO’s associated with port FDO. I generated a memory dump and tried to analyse the device tree and found following.

When i execute drvobj on iscsi port driver i get following

STEP 1

0: kd> !drvobj iScsiPrt
Driver object (fffffa806e295be0) is for:
\Driver\iScsiPrt
Driver Extension List: (id , addr)
(fffff88000d4c090 fffffa806e2d7810)
Device Object list:
fffffa808d59f8c0 fffffa808d5909c0 fffffa805928d9c0 fffffa808d0bb8b0 fffffa806e2e5060

fffffa806e2e5060 is a port PDO which is returned by MS MPIO framework during device discovery and is input to the MS MPIO API DsmGetAssociatedDevice() .

STEP 2

0: kd> !devobj fffffa806e2e5060
Device object (fffffa806e2e5060) is for:
RaidPort5 \Driver\iScsiPrt DriverObject fffffa806e295be0 Current Irp 00000000 RefCount 0 Type 00000004 Flags 00000050 Dacl fffff9a1000cac71 DevExt fffffa806e2e51b0 DevObjExt fffffa806e2e5b40 ExtensionFlags (0000000000) AttachedTo (Lower) fffffa80310a54d0 \Driver\PnpManager Device queue is not busy.

This does not give me DevNode object and i want to know how to enumerate the children associated with device object fffffa806e2e5060 However if i run same command on other device objects from step 1,we get devNode

STEP 3

0: kd> !devobj fffffa808d59f8c0
Device object (fffffa808d59f8c0) is for:
00000199 \Driver\iScsiPrt DriverObject fffffa806e295be0 Current Irp 00000000 RefCount 0 Type 00000007 Flags 00001050 Dacl fffff9a1004db700 DevExt fffffa808d59fa10 DevObjExt fffffa808d59fe90 DevNode fffffa808d6519e0 ExtensionFlags (0x00000800)
Unknown flags 0x00000800 AttachedDevice (Upper) fffffa808d5ad9d0 \Driver\Disk Device queue is not busy.

However devNode is listed for this device.

I have following queries

How i can list the childrens associated with port PDO fffffa806e2e5060
When i ran !devnode 0 1 i got following output , Please note fffffa806e2e5060 PDO is not listed in below output . However it was listed by WinDBG in step 1. Why it is not listed when we executed !devNode 0 1

DevNode 0xfffffa80310a5200 for PDO 0xfffffa80310a54d0
InstancePath is “Root\ISCSIPRT\0000”
ServiceName is “iScsiPrt”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xfffffa808d581d90 for PDO 0xfffffa808d0bb8b0
InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000827”
ServiceName is “disk”
State = DeviceNodeQueryRemoved (0x310)
Previous State = DeviceNodeStarted (0x308)
DevNode 0xfffffa808d582d90 for PDO 0xfffffa805928d9c0
InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000927”
ServiceName is “disk”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xfffffa808d6578a0 for PDO 0xfffffa808d5909c0
InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000027”
ServiceName is “disk”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
DevNode 0xfffffa808d6519e0 for PDO 0xfffffa808d59f8c0
InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000127”
ServiceName is “disk”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)

thanks for your time and consideration.

Thanks,
Rajesh

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Raj_yalgar · July 25, 2013, 3:13am

Hi Kenny,
Thanks for response.I am trying to troubleshoot why ISCSI devices are not
getting discovered by our custom DSM on certain server machine running
WS2008 R2. I have custom DSM driver in the driver stack . One of the
machine where the ISCSI discovery is failing, we see that MPIO system
call(DsmGetAssociatedDevice()
)being made by DSM is not returning any PDO associated with portFDO. I
want to check why this API is failing .
Hence i generated a manual kernel dump and wanted to check if i can
enumerate the PDO associated with port driver.

I tried removing MPIO as well and i could see that the disks are getting
recognised by device manager.
This discovery process fails with only software iscsi and converged network
adapater . However it passes with hardware iscsi .
This symptom is being observed in certain machines only.

thanks,
Rajesh

On Thu, Jul 25, 2013 at 9:28 AM, Speer, Kenny wrote:

> What is the actual problem you’re trying to solve? Do you have a driver
> in the stack? My first inclination is that the MS iSCSI stack is
> relatively solid and I’d be surprised if there was an issue in the
> discovery process.
>
> My first suggestion is to remove MPIO, and use a single iSCSI session to
> validate discovery. Then use a network trace to analyze the iSCSI
> discovery process. The device objects you are listing are below the MPIO
> stack and represent the PDO’s enumerated by the iSCSI port driver.
>
> ~kenny
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
> Sent: Wednesday, July 24, 2013 8:41 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Query Regarding PDO children enumeration
>
> Hi Experts,
> I am looking in to an iscsi lun discovery issue on windows server 2008 R2.
> I am using micosoft MPIO framework and MSDSM software. One of micosoft
> MPIO API DsmGetAssociatedDevice() is failing to return me the PDO’s
> associated with port FDO. I generated a memory dump and tried to analyse
> the device tree and found following.
>
> When i execute drvobj on iscsi port driver i get following
>
> STEP 1
>
> 0: kd> !drvobj iScsiPrt
> Driver object (fffffa806e295be0) is for:
> \Driver\iScsiPrt
> Driver Extension List: (id , addr)
> (fffff88000d4c090 fffffa806e2d7810)
> Device Object list:
> fffffa808d59f8c0 fffffa808d5909c0 fffffa805928d9c0 fffffa808d0bb8b0
> fffffa806e2e5060
>
> fffffa806e2e5060 is a port PDO which is returned by MS MPIO framework
> during device discovery and is input to the MS MPIO API
> DsmGetAssociatedDevice() .
>
>
> STEP 2
>
> 0: kd> !devobj fffffa806e2e5060
> Device object (fffffa806e2e5060) is for:
> RaidPort5 \Driver\iScsiPrt DriverObject fffffa806e295be0 Current Irp
> 00000000 RefCount 0 Type 00000004 Flags 00000050 Dacl fffff9a1000cac71
> DevExt fffffa806e2e51b0 DevObjExt fffffa806e2e5b40 ExtensionFlags
> (0000000000) AttachedTo (Lower) fffffa80310a54d0 \Driver\PnpManager Device
> queue is not busy.
>
> This does not give me DevNode object and i want to know how to enumerate
> the children associated with device object fffffa806e2e5060 However if i
> run same command on other device objects from step 1,we get devNode
>
> STEP 3
>
> 0: kd> !devobj fffffa808d59f8c0
> Device object (fffffa808d59f8c0) is for:
> 00000199 \Driver\iScsiPrt DriverObject fffffa806e295be0 Current Irp
> 00000000 RefCount 0 Type 00000007 Flags 00001050 Dacl fffff9a1004db700
> DevExt fffffa808d59fa10 DevObjExt fffffa808d59fe90 DevNode fffffa808d6519e0
> ExtensionFlags (0x00000800)
> Unknown flags 0x00000800 AttachedDevice
> (Upper) fffffa808d5ad9d0 \Driver\Disk Device queue is not busy.
>
> However devNode is listed for this device.
>
> I have following queries
> 1) How i can list the childrens associated with port PDO fffffa806e2e5060
> 2) When i ran !devnode 0 1 i got following output , Please note
> fffffa806e2e5060 PDO is not listed in below output . However it was
> listed by WinDBG in step 1. Why it is not listed when we executed !devNode
> 0 1
>
> DevNode 0xfffffa80310a5200 for PDO 0xfffffa80310a54d0
> InstancePath is “Root\ISCSIPRT\0000”
> ServiceName is “iScsiPrt”
> State = DeviceNodeStarted (0x308)
> Previous State = DeviceNodeEnumerateCompletion (0x30d)
> DevNode 0xfffffa808d581d90 for PDO 0xfffffa808d0bb8b0
> InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000827”
> ServiceName is “disk”
> State = DeviceNodeQueryRemoved (0x310)
> Previous State = DeviceNodeStarted (0x308)
> DevNode 0xfffffa808d582d90 for PDO 0xfffffa805928d9c0
> InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000927”
> ServiceName is “disk”
> State = DeviceNodeStarted (0x308)
> Previous State = DeviceNodeEnumerateCompletion (0x30d)
> DevNode 0xfffffa808d6578a0 for PDO 0xfffffa808d5909c0
> InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000027”
> ServiceName is “disk”
> State = DeviceNodeStarted (0x308)
> Previous State = DeviceNodeEnumerateCompletion (0x30d)
> DevNode 0xfffffa808d6519e0 for PDO 0xfffffa808d59f8c0
> InstancePath is “SCSI\Disk&Ven_HP&Prod_HSV360\1&1c121344&0&000127”
> ServiceName is “disk”
> State = DeviceNodeStarted (0x308)
> Previous State = DeviceNodeEnumerateCompletion (0x30d)
>
> thanks for your time and consideration.
>
> Thanks,
> Rajesh
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Alex_Grig · July 25, 2013, 10:19am

iSCSIPRT is root-enumerated, this is why you don’t get devnode for it.

If you see iSCSI discovery failing, check the iSCSI control panel applet, and also capture the network trace of the connection. You can use MS netmon or Wireshark for that. Any errors will be also posted in the system event log.

Doron_Holan · July 25, 2013, 10:35am

Root enumerated devices still have a devnode and pdo.

d

Bent from my phone

From: xxxxx@broadcom.com mailto:xxxxx
Sent: ?7/?25/?2013 7:19 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Query Regarding PDO children enumeration

iSCSIPRT is root-enumerated, this is why you don’t get devnode for it.

If you see iSCSI discovery failing, check the iSCSI control panel applet, and also capture the network trace of the connection. You can use MS netmon or Wireshark for that. Any errors will be also posted in the system event log.

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

Raj_yalgar · July 25, 2013, 11:51am

Hi,
Thanks for the response. ISCSI discovery happens properly if i use a single
path/multiple path without MPIO installed. When i use MPIO with custom DSM
i see this problem on certain server model . Is there any document which
describes MS software ISCSI stack in detail. I believe for software ISCSI
on WS 2008 R2 , the port/miniport driver is from MS. Any idea how i can dig
further as to why MPIO API *DsmGetAssociatedDevice*() is failing to return
PDO associated with portFdo.

Do you think exploring a manually generated kernel dump can give some
insight ?
From the MPIO header file the API description looks as below

*PDSM_IDS DsmGetAssociatedDevice( *
* __in IN PVOID MPIOContext,*
* __in IN PDEVICE_OBJECT PortFdo,*
* __in IN UCHAR DeviceType*
* );*
*/*++*
*
*
*Routine Description:*
*
*
* If the DSM needs to acquire information from other devices (such as a
controller), this*
* routine can be used to get a list of the PDO’s associated with PortFdo.
*
*
*
*Arguments:*
*
*
* PortFdo - Port driver FDO passed to InquireDriver.*
* DeviceType - Indicates the SCSI DeviceType to return.*
*
*
*Return Value:*
*
*
* Pointer to a DSM_ID structure, where IdList entries are
PDEVICE_OBJECT. It is the*
* reponsibility of the DSM to free the buffer.*
*
*
*–*/*

thanks
Rajesh

On Thu, Jul 25, 2013 at 7:48 PM, wrote:

> iSCSIPRT is root-enumerated, this is why you don’t get devnode for it.
>
> If you see iSCSI discovery failing, check the iSCSI control panel applet,
> and also capture the network trace of the connection. You can use MS netmon
> or Wireshark for that. Any errors will be also posted in the system event
> log.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

OSR_Community_User · July 25, 2013, 12:18pm

You earlier stated you are using the MSDSM, but you also have your own DSM. MPIO only allows a single DSM to claim devices. You cannot use the MSDSM and your own DSM to claim the same device. The MSDSM is designed to always claim a device if no other DSM has claimed it. If your DSM is not claiming the devices, I would expect random behavior from the MPIO APIs when called by your DSM.

What information are you trying obtain? What problem are you trying to solve?

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Raj yalgar
Sent: Thursday, July 25, 2013 8:51 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Query Regarding PDO children enumeration

Hi,
Thanks for the response. ISCSI discovery happens properly if i use a single path/multiple path without MPIO installed. When i use MPIO with custom DSM i see this problem on certain server model . Is there any document which describes MS software ISCSI stack in detail. I believe for software ISCSI on WS 2008 R2 , the port/miniport driver is from MS. Any idea how i can dig further as to why MPIO API DsmGetAssociatedDevice() is failing to return PDO associated with portFdo.

Do you think exploring a manually generated kernel dump can give some insight ?
From the MPIO header file the API description looks as below

PDSM_IDS DsmGetAssociatedDevice(
__in IN PVOID MPIOContext,
__in IN PDEVICE_OBJECT PortFdo,
__in IN UCHAR DeviceType
);
/*++

Routine Description:

If the DSM needs to acquire information from other devices (such as a controller), this
routine can be used to get a list of the PDO’s associated with PortFdo.

Arguments:

PortFdo - Port driver FDO passed to InquireDriver.
DeviceType - Indicates the SCSI DeviceType to return.

Return Value:

Pointer to a DSM_ID structure, where IdList entries are PDEVICE_OBJECT. It is the
reponsibility of the DSM to free the buffer.

–*/

thanks
Rajesh

On Thu, Jul 25, 2013 at 7:48 PM, > wrote:
iSCSIPRT is root-enumerated, this is why you don’t get devnode for it.

If you see iSCSI discovery failing, check the iSCSI control panel applet, and also capture the network trace of the connection. You can use MS netmon or Wireshark for that. Any errors will be also posted in the system event log.

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Raj_yalgar · July 25, 2013, 2:02pm

I am trying with MSDSM(comes default in WS2008) and custom DSM (which is
again variant for MS DSM ). By design MPIO framework gives custom DSM
chance a to claim devices. However during device discovery , MPIO
framework makes calls to certain functions exported by custom DSM . One
such exported function is failing as reasoned above(Due to *
DsmGetAssociatedDevice*() failure) . This is resulting in a situation where
this ISCSI lun is neither claimed by custom DSM nor MS-DSM.

I tried capturing MPIO logs but its a binary file and windows system event
are not much help here as i am just seeing MPIO event 1 and 2 which stand
for psuedo lun creation and new path addition respectively.I just see psudo
LUN in device manager with yellow bang as no DSM has claimed it.

I may need to contact MS but before that i want to investigate or collect
more data which can help me to identify why PDO are not getting enumerated
by port driver via call to *DsmGetAssociatedDevice. *Hence i thought of
generating manual dump and try exploring state of PDO enumeration by port
driver. Let me know if you have better way to troubleshoot it.

BTW without MPIO the ISCSI luns with single/multiple path are discovered by
device manager.
*
*
thanks for your time and consideration.

Adios,
Rajesh

On Thu, Jul 25, 2013 at 9:47 PM, Speer, Kenny wrote:

> You earlier stated you are using the MSDSM, but you also have your own
> DSM. MPIO only allows a single DSM to claim devices. You cannot use the
> MSDSM and your own DSM to claim the same device. The MSDSM is designed to
> always claim a device if no other DSM has claimed it. If your DSM is not
> claiming the devices, I would expect random behavior from the MPIO APIs
> when called by your DSM.
>
>
>
> What information are you trying obtain? What problem are you trying to
> solve?
>
> ****
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Raj yalgar
> Sent: Thursday, July 25, 2013 8:51 AM
>
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Query Regarding PDO children enumeration
>
>
>
> Hi,
>
> Thanks for the response. ISCSI discovery happens properly if i use a
> single path/multiple path without MPIO installed. When i use MPIO with
> custom DSM i see this problem on certain server model . Is there any
> document which describes MS software ISCSI stack in detail. I believe for
> software ISCSI on WS 2008 R2 , the port/miniport driver is from MS. Any
> idea how i can dig further as to why MPIO API DsmGetAssociatedDevice()
> is failing to return PDO associated with portFdo.
>
>
>
> Do you think exploring a manually generated kernel dump can give some
> insight ?
>
> From the MPIO header file the API description looks as below
>
>
>
> *PDSM_IDS DsmGetAssociatedDevice(
>
> * in IN PVOID MPIOContext, *****
>
> * in IN PDEVICE_OBJECT PortFdo,
>
> * __in IN UCHAR DeviceType***
>
> * );*****
>
> /++ *
>
>
>
> Routine Description:
>
> ****
>
> * If the DSM needs to acquire information from other devices (such as
> a controller), this
>
> * routine can be used to get a list of the PDO’s associated with
> PortFdo.
>
> ****
>
> *Arguments:
>
>
>
> * PortFdo - Port driver FDO passed to InquireDriver.
>
> * DeviceType - Indicates the SCSI DeviceType to return. *
>
>
>
> Return Value:
>
> ****
>
> * Pointer to a DSM_ID structure, where IdList entries are
> PDEVICE_OBJECT. It is the
>
> * reponsibility of the DSM to free the buffer.
>
> ****
>
> –/ *
>
>
>
>
>
>
>
> thanks
>
> Rajesh
>
>
>
> On Thu, Jul 25, 2013 at 7:48 PM, wrote:
>
> iSCSIPRT is root-enumerated, this is why you don’t get devnode for it.
>
> If you see iSCSI discovery failing, check the iSCSI control panel applet,
> and also capture the network trace of the connection. You can use MS netmon
> or Wireshark for that. Any errors will be also posted in the system event
> log.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> ****
>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer ****
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

OSR_Community_User · July 25, 2013, 3:57pm

That’s correct behavior. If your DSM has registered to claim a device, then MSDSM will never be called even if you fail DsmInquire(). So this is an MPIO issue with your driver, this does not appear to have anything to do with iSCSI or discovery. You must claim the devices. The Pord FDO and Child Device Objects are both passed to DsmInquire().

DsmGetAssociatedDevice() is not normally required by a DSM. I suggest removing the need to use DsmGetAssociatedDevice() unless you have a compelling reason to use it (you need a controller device object, etc). This is not a required API.

You’ve stated a symptom (the API fails) but not the real problem you are trying to solve. Why do you need to make the call to DsmGetAssociatedDevice()?

~kenny

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Raj yalgar
Sent: Thursday, July 25, 2013 11:02 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Query Regarding PDO children enumeration

I am trying with MSDSM(comes default in WS2008) and custom DSM (which is again variant for MS DSM ). By design MPIO framework gives custom DSM chance a to claim devices. However during device discovery , MPIO framework makes calls to certain functions exported by custom DSM . One such exported function is failing as reasoned above(Due to DsmGetAssociatedDevice() failure) . This is resulting in a situation where this ISCSI lun is neither claimed by custom DSM nor MS-DSM.

I tried capturing MPIO logs but its a binary file and windows system event are not much help here as i am just seeing MPIO event 1 and 2 which stand for psuedo lun creation and new path addition respectively.I just see psudo LUN in device manager with yellow bang as no DSM has claimed it.

I may need to contact MS but before that i want to investigate or collect more data which can help me to identify why PDO are not getting enumerated by port driver via call to DsmGetAssociatedDevice. Hence i thought of generating manual dump and try exploring state of PDO enumeration by port driver. Let me know if you have better way to troubleshoot it.

BTW without MPIO the ISCSI luns with single/multiple path are discovered by device manager.

thanks for your time and consideration.

Adios,
Rajesh

On Thu, Jul 25, 2013 at 9:47 PM, Speer, Kenny > wrote:
You earlier stated you are using the MSDSM, but you also have your own DSM. MPIO only allows a single DSM to claim devices. You cannot use the MSDSM and your own DSM to claim the same device. The MSDSM is designed to always claim a device if no other DSM has claimed it. If your DSM is not claiming the devices, I would expect random behavior from the MPIO APIs when called by your DSM.

What information are you trying obtain? What problem are you trying to solve?

From: xxxxx@lists.osr.com mailto:xxxxx [mailto:xxxxx@lists.osr.com mailto:xxxxx] On Behalf Of Raj yalgar
Sent: Thursday, July 25, 2013 8:51 AM

To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Query Regarding PDO children enumeration

Hi,
Thanks for the response. ISCSI discovery happens properly if i use a single path/multiple path without MPIO installed. When i use MPIO with custom DSM i see this problem on certain server model . Is there any document which describes MS software ISCSI stack in detail. I believe for software ISCSI on WS 2008 R2 , the port/miniport driver is from MS. Any idea how i can dig further as to why MPIO API DsmGetAssociatedDevice() is failing to return PDO associated with portFdo.

Do you think exploring a manually generated kernel dump can give some insight ?
From the MPIO header file the API description looks as below

PDSM_IDS DsmGetAssociatedDevice(
in IN PVOID MPIOContext,
in IN PDEVICE_OBJECT PortFdo,
__in IN UCHAR DeviceType
);
/++

Routine Description:

If the DSM needs to acquire information from other devices (such as a controller), this
routine can be used to get a list of the PDO’s associated with PortFdo.

Arguments:

PortFdo - Port driver FDO passed to InquireDriver.
DeviceType - Indicates the SCSI DeviceType to return.

Return Value:

Pointer to a DSM_ID structure, where IdList entries are PDEVICE_OBJECT. It is the
reponsibility of the DSM to free the buffer.

–/

thanks
Rajesh

On Thu, Jul 25, 2013 at 7:48 PM, > wrote:
iSCSIPRT is root-enumerated, this is why you don’t get devnode for it.

If you see iSCSI discovery failing, check the iSCSI control panel applet, and also capture the network trace of the connection. You can use MS netmon or Wireshark for that. Any errors will be also posted in the system event log.

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

Raj_yalgar · July 30, 2013, 11:47am

Hi Kenny,
I agree that MS DSM will never claim devices.However for custom DSM , we
are required to use DsmGetAssociatedDevice() to support WMI call returning
controller information. Our client storage has multiple controller’s and
DSM implementation support WMI call for getting controller information
corresponding to the given device objects. It appears that port or mpio
bus driver are having issue enumerating controller objects for this
hardware. Let me know what you opine.

thanks for your time.

Adios,
Rajesh

On Fri, Jul 26, 2013 at 1:26 AM, Speer, Kenny wrote:

> That?s correct behavior. If your DSM has registered to claim a device,
> then MSDSM will never be called even if you fail DsmInquire(). So this is
> an MPIO issue with your driver, this does not appear to have anything to do
> with iSCSI or discovery. You must claim the devices. The Pord FDO and
> Child Device Objects are both passed to DsmInquire().
>
> **
>
> DsmGetAssociatedDevice() is not normally required by a DSM. I suggest
> removing the need to use DsmGetAssociatedDevice() unless you have a
> compelling reason to use it (you need a controller device object, etc).
> This is not a required API.
>
> ****
>
> You?ve stated a symptom (the API fails) but not the real problem you are
> trying to solve. Why do you need to make the call to
> DsmGetAssociatedDevice()?
>
>
>
> ~kenny
>
> ****
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Raj yalgar
> Sent: Thursday, July 25, 2013 11:02 AM
>
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Query Regarding PDO children enumeration
>
> **
>
> I am trying with MSDSM(comes default in WS2008) and custom DSM (which is
> again variant for MS DSM ). By design MPIO framework gives custom DSM
> chance a to claim devices. However during device discovery , MPIO
> framework makes calls to certain functions exported by custom DSM . One
> such exported function is failing as reasoned above(Due to
> DsmGetAssociatedDevice() failure) . This is resulting in a situation
> where this ISCSI lun is neither claimed by custom DSM nor MS-DSM.
>
> ****
>
> I tried capturing MPIO logs but its a binary file and windows system
> event are not much help here as i am just seeing MPIO event 1 and 2 which
> stand for psuedo lun creation and new path addition respectively.I just see
> psudo LUN in device manager with yellow bang as no DSM has claimed it.
>
>
>
> I may need to contact MS but before that i want to investigate or collect
> more data which can help me to identify why PDO are not getting enumerated
> by port driver via call to DsmGetAssociatedDevice. Hence i thought of
> generating manual dump and try exploring state of PDO enumeration by port
> driver. Let me know if you have better way to troubleshoot it.
>
> ****
>
> BTW without MPIO the ISCSI luns with single/multiple path are discovered
> by device manager.
>
>
>
> thanks for your time and consideration.
>
> ****
>
> Adios,
>
> Rajesh
>
> ****
>
> On Thu, Jul 25, 2013 at 9:47 PM, Speer, Kenny
> wrote:
>
> You earlier stated you are using the MSDSM, but you also have your own
> DSM. MPIO only allows a single DSM to claim devices. You cannot use the
> MSDSM and your own DSM to claim the same device. The MSDSM is designed to
> always claim a device if no other DSM has claimed it. If your DSM is not
> claiming the devices, I would expect random behavior from the MPIO APIs
> when called by your DSM.
>
>
>
> What information are you trying obtain? What problem are you trying to
> solve?
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Raj yalgar
> Sent: Thursday, July 25, 2013 8:51 AM
>
>
> To: Windows System Software Devs Interest List
>
> Subject: Re: [ntdev] Query Regarding PDO children enumeration**
>
>
>
> Hi,
>
> Thanks for the response. ISCSI discovery happens properly if i use a
> single path/multiple path without MPIO installed. When i use MPIO with
> custom DSM i see this problem on certain server model . Is there any
> document which describes MS software ISCSI stack in detail. I believe for
> software ISCSI on WS 2008 R2 , the port/miniport driver is from MS. Any
> idea how i can dig further as to why MPIO API DsmGetAssociatedDevice()
> is failing to return PDO associated with portFdo.
>
>
>
> Do you think exploring a manually generated kernel dump can give some
> insight ?
>
> From the MPIO header file the API description looks as below
>
>
>
> PDSM_IDS DsmGetAssociatedDevice(
>
> * in IN PVOID MPIOContext, *****
>
> * in IN PDEVICE_OBJECT PortFdo,
>
> * __in IN UCHAR DeviceType
>
> * );*****
>
> /++ *
>
>
>
> *Routine Description:
>
>
>
> * If the DSM needs to acquire information from other devices (such as
> a controller), this
>
> * routine can be used to get a list of the PDO’s associated with
> PortFdo.
>
>
>
> Arguments:
>
>
>
> * PortFdo - Port driver FDO passed to InquireDriver.
>
> * DeviceType - Indicates the SCSI DeviceType to return. *
>
>
>
> *Return Value:
>
>
>
> * Pointer to a DSM_ID structure, where IdList entries are
> PDEVICE_OBJECT. It is the
>
> * reponsibility of the DSM to free the buffer.
>
>
>
> –/
>
>
>
>
>
>
>
> thanks
>
> Rajesh
>
>
>
> On Thu, Jul 25, 2013 at 7:48 PM, wrote:
>
> iSCSIPRT is root-enumerated, this is why you don’t get devnode for it.
>
> If you see iSCSI discovery failing, check the iSCSI control panel applet,
> and also capture the network trace of the connection. You can use MS netmon
> or Wireshark for that. Any errors will be also posted in the system event
> log.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> ****
>
> — NTDEV is sponsored by OSR Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer ****
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>