Handle power Irp when 2 devices supported

[John]

I have a PCI device that can be two devices of the same type.

During pnp_start_device phase, the driver will determine if the device
has been configured with the secondary device. If it has, a new PDO is
created and saved as the childPDO of the primary device.

When the primary device receives the IRP_MJ_POWER indicating the
system is shutting down, should I send this Irp to the ChildPDO? If
yes, how would I do it?

Currently the device is not doing this and the system will not shut
down. Instead, after a while, the computer will restart instead of
shutting down. When the secondary device is not installed (no childPDO
created), the system shuts down normally.

Thanks

[Doron Holan [MSFT]]

did you report your childPDO via QDR/BusRelations? if so, the child stack
will see the Sx irp before teh parent stack sees the Sx irp automatically.
you should never be fwding power irps to between diff pnp stacks

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"John" <jvas...@cox.net> wrote in message
news:32i394h0d4bgqin6k...@4ax.com...

[John]

On Thu, 31 Jul 2008 10:29:54 -0700, "Doron Holan [MSFT]"
<dor...@online.microsoft.com> wrote:

>did you report your childPDO via QDR/BusRelations? if so, the child stack
>will see the Sx irp before teh parent stack sees the Sx irp automatically.
>you should never be fwding power irps to between diff pnp stacks
>
>d

After reviewing the code, I do report the childPDO via
QDR/BufRelations.

So now I really don't know what is going on and why the computer
restarts instead of shutting down like it does when there is no
childPDO

[John]

On Thu, 31 Jul 2008 10:29:54 -0700, "Doron Holan [MSFT]"
<dor...@online.microsoft.com> wrote:

>did you report your childPDO via QDR/BusRelations? if so, the child stack
>will see the Sx irp before teh parent stack sees the Sx irp automatically.
>you should never be fwding power irps to between diff pnp stacks
>
>d

I am seeing, in my print statements, something that doesn't make sense
to me.

Everything starts to look ok. I get the AddDevice, I create the
ChildPDO, I get the IRP_MN_QUERY_DEVICE_RELATIONS (QDR) for the
primary device and report back the relations.

Then I get a bunch of other PnP Query Irps such as capability,
resource requiremtn, and others.
Then towards the end, I get another QDR but its not for the primary or
secondary device. I have no idea who this QDR is for. there is no
Childpdo attached. I then get another QDR for the child and process
it. The I get the QDR for the primary channel containing the childPDO.
I did the same processing as the first time I got the QDR after the
AddDevice was processed. I then get another QDR for that stranger (not
the primary or secondary). Then finally I get one last QDR for the
childpdo and process like I did before.

Why do I get so many QDRs?

[Doron Holan [MSFT]]

what is the relations type that you being queried for in the QDR? it is
normal to be repeatedly requeried for busrelations. you just return the PDO
each time in the relations list

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"John" <jvas...@cox.net> wrote in message

news:036694l1te183q8i6...@4ax.com...

[John]

On Fri, 1 Aug 2008 11:44:21 -0700, "Doron Holan [MSFT]"
<dor...@online.microsoft.com> wrote:

>what is the relations type that you being queried for in the QDR? it is
>normal to be repeatedly requeried for busrelations. you just return the PDO
>each time in the relations list
>
>d

It is busrelations.

It's been a while since I visited this code and I had to sit down and
take a good look as to what was happening.
During the AddDevice phase, the driver created the FDO for its device.
Then the IRP_MN_START_DEVICE occurred. Here is where the driver
created the PDO for the secondary device (This is where I got
confused, "I'm much better now".

When the QDR was processed. the driver notified the system about the
busrelations of the secondary device.

The AddDevice phase started for the secondary device and the driver
created the FDO for that device. Initialization of the secondary
channel occurred when the IRP_MN_START_DEVICE was received for the
secondary channel. Everybody was happy.

I used the sample code from Walter Oney book, "Programming the
Microsoft Windows Driver Model".

If you're familiar with this book, it talked about wearing the PDO hat
or FDO hat while processing PNP IRPs. All this worked just fine. But I
failed to implement the PDO/FDO hats scheme for the Power IRPs. All
processing occured for the FDO. If the PDO was received the driver
should just complete the IRP. I didn't do that and I think this is
where my problem lies.

I'm going to add the PDO hat for the secondary device and see what
happens.

[Doron Holan [MSFT]]

i suggest that you look at porting to KMDF, all of this crud is taken care
of for you w/out you writing a single line of code.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"John" <jvas...@cox.net> wrote in message

news:oq5e949b717a5eu8b...@4ax.com...

[John]

On Mon, 4 Aug 2008 11:22:52 -0700, "Doron Holan [MSFT]"
<dor...@online.microsoft.com> wrote:

>i suggest that you look at porting to KMDF, all of this crud is taken care
>of for you w/out you writing a single line of code.
>
>d

That would be great. However, I just don't have the time. The driver
overall works; just a few bugs pop-up once in a while. Plus upper
management won't allow me to change it because it (the driver) works.
I even tested the driver in Vista and no problems encountered, so this
driver will probably never get changed to KMDF.

I did fix my problem though. I just didn't handle the power management
correctly for the multifunction adapter.

Thanks for your suggestions.

[Doron Holan [MSFT]]

if it is based on oney's book (not to say that it is completely buggy,
overall it is good), you will have lots of latent bugs taht will creep up on
you over time.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"John" <jvas...@cox.net> wrote in message

news:anpe945tcr8fm56oc...@4ax.com...

[Maxim S. Shatskih]

Can you tell us at least some of the buggy approaches in Oney's book and
the sample code from it? What about the remove locks and Oney's description of
their logic and why are they needed?

Are approaches from the real-world Windows drivers shipped as sample source
with WDK also buggy?

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

"Doron Holan [MSFT]" <dor...@online.microsoft.com> wrote in message
news:eIdNWtn9...@TK2MSFTNGP05.phx.gbl...

[Doron Holan [MSFT]]

selective suspend is problematic, coordinating io queues with power state is
also kinda racey. these are all hard problems that are very difficult to
get right regardless of where the code comes from. some of the wdk samples
(bulkusb comes to mind) do suffer from the same problems, we are actively
trying to identify these issues and fix them in future wdk releases...

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
news:OND0kUu9...@TK2MSFTNGP04.phx.gbl...