More discuss for http://www.osronline.com/showThread.cfm?link=162145
I find that PsCreateSystemThread cannot work when resume from hibernate
either, I mean before scsi miniport driver can work well.
There are some system threads created by my bus driver, which are used
to initialize or change state for child devices including storage device
in page/dump/hibernate path. It seems that these system threads doesn’t
take effect when system is start to resume from hibernate but scsi
miniport cannot work well at that time. Without the help of those system
thread, my scsi miniport driver cannot initialize storage device
properly. So I want to know when those system threads will take effect
in system? or in fact, those system threads cannot work without scsi
miniport driver working properly.
I use PsCreateSystemThread(hStandbyHandle, THREAD_ALL_ACCESS, NULL,
NULL, NULL, StandbyThread, StandbyThreadContext) to create those system
threads when bus driver FDO is starting.
Thanks
Wayne
All what I said is when driver verify is enabled with default setting
for my driver set. If I disable driver verify, all things go well.
Wayne
Wayne Gong wrote:
More discuss for http://www.osronline.com/showThread.cfm?link=162145
I find that PsCreateSystemThread cannot work when resume from
hibernate either, I mean before scsi miniport driver can work well.
There are some system threads created by my bus driver, which are used
to initialize or change state for child devices including storage
device in page/dump/hibernate path. It seems that these system threads
doesn’t take effect when system is start to resume from hibernate but
scsi miniport cannot work well at that time. Without the help of those
system thread, my scsi miniport driver cannot initialize storage
device properly. So I want to know when those system threads will take
effect in system? or in fact, those system threads cannot work without
scsi miniport driver working properly.
I use PsCreateSystemThread(hStandbyHandle, THREAD_ALL_ACCESS, NULL,
NULL, NULL, StandbyThread, StandbyThreadContext) to create those
system threads when bus driver FDO is starting.
Thanks
Wayne
NTDEV is sponsored by OSR
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
Any kernel routine marked as callable at PASSIVE_LEVEL could have its
code paged out. The verifier pages out all such code for you to make
sure that this is actually tested and that you find it now instead of a
user finding it later.
PsCreateSystemThread will hang if the page file is not available. Work
items can be scheduled but will not be run. Probably lots of other
things too.
Leave your threads running when you hibernate but leave them waiting on
a signal, then wake them up when you resume.
James
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-379958-
xxxxx@lists.osr.com] On Behalf Of Wayne Gong
Sent: Monday, 7 September 2009 17:49
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] PsCreateSystemThread cannot work when resume from
hibernate
All what I said is when driver verify is enabled with default setting
for my driver set. If I disable driver verify, all things go well.
Wayne
Wayne Gong wrote:
> More discuss for http://www.osronline.com/showThread.cfm?link=162145
>
> I find that PsCreateSystemThread cannot work when resume from
> hibernate either, I mean before scsi miniport driver can work well.
>
> There are some system threads created by my bus driver, which are
used
> to initialize or change state for child devices including storage
> device in page/dump/hibernate path. It seems that these system
threads
> doesn’t take effect when system is start to resume from hibernate
but
> scsi miniport cannot work well at that time. Without the help of
those
> system thread, my scsi miniport driver cannot initialize storage
> device properly. So I want to know when those system threads will
take
> effect in system? or in fact, those system threads cannot work
without
> scsi miniport driver working properly.
>
> I use PsCreateSystemThread(hStandbyHandle, THREAD_ALL_ACCESS, NULL,
> NULL, NULL, StandbyThread, StandbyThreadContext) to create those
> system threads when bus driver FDO is starting.
>
> Thanks
> Wayne
>
> —
> NTDEV is sponsored by OSR
>
> 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
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
Thanks for your clarification. It seems that I meet a dead lock. Please
correct me if anything wrong.
Without SCSI miniport driver work properly, those threads won’t be page
in and take effect. But without those threads working, my scsi miniport
driver cannot re-initialize and service disk I/Os. My scsi miniport
driver needs to use those threads to connect to the backend driver to
deal with disk I/Os. I’ve tried to re-initialized disk device when scsi
miniport driver get ScsiRestartAdapter or bus driver get hibernate
notification for boot device, both were failed because those threads
didn’t work to service scsi miniport driver re-initialize operation.
Thanks
Wayne
James Harper wrote:
Any kernel routine marked as callable at PASSIVE_LEVEL could have its
code paged out. The verifier pages out all such code for you to make
sure that this is actually tested and that you find it now instead of a
user finding it later.
PsCreateSystemThread will hang if the page file is not available. Work
items can be scheduled but will not be run. Probably lots of other
things too.
Leave your threads running when you hibernate but leave them waiting on
a signal, then wake them up when you resume.
James
>
Thanks for your clarification. It seems that I meet a dead lock.
Please
correct me if anything wrong.
Without SCSI miniport driver work properly, those threads won’t be
page
in and take effect. But without those threads working, my scsi
miniport
driver cannot re-initialize and service disk I/Os. My scsi miniport
driver needs to use those threads to connect to the backend driver to
deal with disk I/Os. I’ve tried to re-initialized disk device when
scsi
miniport driver get ScsiRestartAdapter or bus driver get hibernate
notification for boot device, both were failed because those threads
didn’t work to service scsi miniport driver re-initialize operation.
It’s not the threads that are paged out, it is the part of the kernel
that holds PsCreateSystemThread and/or some system data that
PsCreateSystemThread uses to do its work. Instead of stopping the
threads at hibernate and starting them again at resume, just keep them
running but waiting on a signal or something so they don’t get up to
mischief while you are in the hibernate or resume.
James
I didn’t stop/start those threads when hibernate/resume, just let them
be there after system start for the first time. The problem is I cannot
find a time to re-initialize disk device. Now I use FDO’s set system
power IRP as a trigger to update FDO state and wake up child devices. At
that time, I will reconnect disk device with backend driver.
Reconnection will failed because those threads are necessary for device
state change watcher.
Thanks
Wayne
James Harper wrote:
It’s not the threads that are paged out, it is the part of the kernel
that holds PsCreateSystemThread and/or some system data that
PsCreateSystemThread uses to do its work. Instead of stopping the
threads at hibernate and starting them again at resume, just keep them
running but waiting on a signal or something so they don’t get up to
mischief while you are in the hibernate or resume.
> I find that PsCreateSystemThread cannot work when resume from hibernate
either, I mean before scsi miniport driver can work well.
Use the async approach (lots of functions with completion callbacks) to execute the resume procedure of your driver, not threads.
With such an approach, you can, for instance, easily send IRPs.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> Use the async approach (lots of functions with completion callbacks) to execute the resume procedure of your driver, not threads.
With such an approach, you can, for instance, easily send IRPs.
I have some system threads created by my bus driver which are used to
detect driver and device state change. I didn’t terminate or recreate
those threads when system is hibernating and resuming. These threads are
necessary for disk and network child device initialization. Without
these thread working properly, my scsi miniport driver cannot
re-initialize disk device even in page/dump/hibernate path. Which time
point can I use as a trigger to execute my resume procedure of my
drivers especially miniport drivers?
thanks
wayne
>
> Use the async approach (lots of functions with completion callbacks)
to
execute the resume procedure of your driver, not threads.
>
> With such an approach, you can, for instance, easily send IRPs.
I have some system threads created by my bus driver which are used to
detect driver and device state change. I didn’t terminate or recreate
those threads when system is hibernating and resuming. These threads
are
necessary for disk and network child device initialization. Without
these thread working properly, my scsi miniport driver cannot
re-initialize disk device even in page/dump/hibernate path. Which time
point can I use as a trigger to execute my resume procedure of my
drivers especially miniport drivers?
Can you break into the debugger there and look at all the blocked
threads? In particular have a look for threads that are waiting on the
page file and work out what it is that they are trying to do.
James
James Harper wrote:
Can you break into the debugger there and look at all the blocked
threads? In particular have a look for threads that are waiting on the
page file and work out what it is that they are trying to do.
I found the problem.
In those thread I created in my bus driver when FDO initializing, there
are some unicode operations. It looks like that those operations are not
allowed when resuming from hibernate with Driver Verify enabled with
default setting.
thanks
wayne
> James Harper wrote:
> Can you break into the debugger there and look at all the blocked
> threads? In particular have a look for threads that are waiting on
the
> page file and work out what it is that they are trying to do.
I found the problem.
In those thread I created in my bus driver when FDO initializing,
there
are some unicode operations. It looks like that those operations are
not
allowed when resuming from hibernate with Driver Verify enabled with
default setting.
Forgot about those. Yes, RtlXxx functions that operate on Unicode
strings do cause a hang if used on resume from hibernate if the paging
device is not started yet.
James