Re: PM IRPs won't complete in KMDF bus driver
- From: "Doron Holan [MSFT]" <doronh@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 6 Feb 2008 16:29:47 -0800
CrashOnCtrlScroll would not work if the keyboard is not yet in D0 to process interrupts.
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.
"DaveH" <DaveH@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:AA4B6C22-988A-4F92-8FB9-961DA8501038@xxxxxxxxxxxxxxxx
CrashOnCtrlScroll doesn't work either, possibly because system is not in S0
yet? I had sent the email to doronh at online-microsoft-com (email on your
profile). I just sent it again through your blog. Hope it gets to you this
time.
"Doron Holan [MSFT]" wrote:
i did not get the email. you can use "CrashOnCtrlScroll" for a ps2 keyboard
to manually initiate a crash dump on win2k w/no debugger attached.
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.
"DaveH" <DaveH@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D58E6995-A396-47F2-A9D3-34A57F5BEEA5@xxxxxxxxxxxxxxxx
> The !poaction on my setup shows the "Allocated power irps (PopIrpList -
> xxxxxxxx)" but doesn't list them. I figured the linked list structure
> should
> be {fLink, bLink, pIrp, pDevObj} which is what I used to extract power
> irps.
>
> I can reproduce the problem on win2k (takes more sleep/resume cycles to
> get
> it to fail compared to Vista) but this is only if debugger is not
> connected,
> so no memory dumps. I tried a PCI dump switch card which didn't work on
> any
> of the failing machines (none have SERR# I'd suppose). Also I wasn't > able
> to
> reproduce it on XP although our original bug report said so.
>
> Doron, I have emailed you the memory dump on Vista. Could you just > confirm
> you've received this as I didn't see any nospam in your email address.
>
> Thanks,
> Dave H
>
> "Doron Holan [MSFT]" wrote:
>
>> On vista, !poaction was updated to dump the power irp req list, it >> would
>> be
>> the output that starts with
>> Allocated power irps (PopIrpList - <pointer>)
>>
>> and then dump each irp with "IRP: ". btw, i think you know this, but >> the
>> LIST_ENTRYs in PopIrpList do not link to PIRPs, but rather another
>> structure
>> which tracks the PIRP.
>>
>> Given the description you have below, i do not come to the same
>> conclusion.
>> STATUS_NOT_SUPPORTED is the default status in the power irp. I think
>> that
>> the power irp has not yet even gone through the top of the stack on >> the
>> way
>> *down* the stack. this is why the pci pdo is still in d3. when the
>> power
>> irp comes back up the stack, kmdf immediately stores the irp >> regardless
>> of
>> the NTSTATUS in it. once stored, it would be dumped in the output of
>> !wdfdevice as a pended D irp.
>>
>> how easy is this to repro on a pre vista machine? i ask b/c of the
>> changes
>> around PoStartNextPowerIrp on vista. starting with vista, this api is >> no
>> longer required and the kernel infrastructure used to maintain the >> power
>> irp
>> gates was removed. the state of these gates (which were flags) was
>> dumped
>> in !podev. a pre vista machine will still have these flags set in the
>> device that !podev can display. this would give us some better clues >> as
>> to
>> how to proceed.
>>
>> is it possible for you to create a full kernel dump and send the dump >> to
>> us?
>> remove the nospam from my email address
>>
>> 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.
>>
>>
>> "DaveH" <DaveH@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:D28A9AD4-A87E-44B7-97DC-2A723FF15553@xxxxxxxxxxxxxxxx
>> > ////////////////////////////////////
>> > The device stack for the bus driver:
>> >
>> > 1: kd> !devstack 83f26798
>> > !DevObj !DrvObj !DevExt ObjectName
>> >> 83f26798 \Driver\<<MyBus>> 83f2e1d8
>> > 83bc2030 \Driver\pci 83bc20e8 NTPNP_PCI0023
>> > !DevNode 837cf758 :
>> > DeviceInst is
>> > "PCI\VEN_xxxx&DEV_xxxx&SUBSYS_xxxxxxxx&REV_00\4&7abb47a&0&0168"
>> > ServiceName is "<<MyBusService>>"
>> >
>> >
>> > ////////////////////////////////////
>> > !podev for the bus and PCI device objects:
>> >
>> > 1: kd> !podev 83f26798
>> > Device object is for:
>> > DriverObject 83f29578
>> > Current Irp 00000000 RefCount 0 Type 00000000 DevFlags 00002004
>> > DO_POWER_PAGABLE
>> > Device queue is not busy.
>> > Device Object Extension: 83f26868:
>> > PowerFlags: 00000040 =>SystemState=0 DeviceState=4
>> > Dope: 00000000:
>> >
>> > 1: kd> !podev 83bc2030
>> > Device object is for:
>> > DriverObject 83d54220
>> > Current Irp 00000000 RefCount 0 Type 00000000 AttachedDev 83f26798
>> > DevFlags
>> > 00001040
>> > Device queue is not busy.
>> > Device Object Extension: 83bc2468:
>> > PowerFlags: 00000040 =>SystemState=0 DeviceState=4
>> > Dope: 00000000:
>> >
>> >
>> > ////////////////////////////////////
>> > Problem occurs mostly on Vista, so no !poreqlist. Also !poaction
>> > doesn't
>> > list the PM IRPs, so I used "dl popirplist" to get the IRPs. The
>> > related
>> > IRPs
>> > are 8 (number of childs) S0 irps pending in child driver, 8 D0 irps
>> > (created
>> > by child after receiving S0) pending in the bus driver and one D0 >> > irp
>> > created
>> > by bus fdo (KMDF) and being pended in bus driver:
>> >
>> > 1: kd> !irp 902558c8 [[D0 irp created by KMDF]]
>> > Irp is active with 3 stacks 2 is current (= 0x9025595c)
>> > No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
>> > cmd flg cl Device File Completion-Context
>> > [ 0, 0] 0 0 00000000 00000000 00000000-00000000
>> >
>> > Args: 00000000 00000000 00000000 00000000
>> >>[ 16, 2] 0 e1 83f26798 00000000 8184b0bf-8883f108 Success Error
>> >>Cancel
>> >>pending
>> > \Driver\<<MyBus>> nt!PopRequestCompletion
>> > Args: 00021100 00000001 00000001 00000002
>> > [ 0, 0] 0 0 00000000 00000000 00000000-8883f108
>> >
>> > Args: 00000000 00000000 00000000 00000000
>> >
>> > The Io_Status_Block of this IRP shows an 0xC00000BB
>> > (STATUS_NOT_SUPPORTED)
>> > status.
>> >
>> >
>> > ////////////////////////////////////
>> >
>> > Could it be that PCI hasn't been able to put the device in D0 for
>> > whatever
>> > reason (!podev shows it's own dev state is still D3), has failed the
>> > request
>> > but KMDF isn't expecting an 0xC00000BB status?
>> >
>> > Also one funny thing which I noticed is the S0 irp which the child
>> > driver
>> > has passed down the stack. This irp is actually being pended on its >> > way
>> > up
>> > until device stack is back in D0. However the !irp shows that the >> > bus
>> > driver
>> > has received a WW rather than a set power irp:
>> >
>> > 1: kd> !irp 902596f8 [[ Note the 16, 0 on first stack, what's going >> > on
>> > here?
>> > ]]
>> > Irp is active with 4 stacks 2 is current (= 0x9025978c)
>> > No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
>> > cmd flg cl Device File Completion-Context
>> > [ 16, 0] 0 0 88e9c030 00000000 88c83dd0-00000000
>> > \Driver\<<MyBus>> Child!SystemPowerCompletion
>> > Args: 00000000 00000000 00000000 00000002
>> >>[ 16, 2] 0 1 88f79040 00000000 00000000-00000000 pending
>> > \Driver\<<MyChild>>
>> > Args: 00021100 00000000 00000001 00000002
>> > [ 16, 2] 0 e1 88f789b0 00000000 81ac97d3-88857108 Success Error
>> > Cancel
>> > pending
>> > \Driver\Serenum nt!PopSystemIrpCompletion
>> > Args: 00021100 00000000 00000001 00000002
>> > [ 0, 0] 0 0 00000000 00000000 00000000-88857108
>> >
>> > Args: 00000000 00000000 00000000 00000000
>> >
>> > I could also post !poaction (long list) if you think it might help.
>> >
>> > Thanks,
>> > DaveH
>> >
>> >
>> > "Doron Holan [MSFT]" wrote:
>> >
>> >> If WdfDevStatePwrPolSystemWakeDeviceWakeEnabledWakeCanceled is the
>> >> current
>> >> power policy state for the FDO then this means that KMDF has >> >> requested
>> >> a
>> >> D0
>> >> power irp and is waiting for it to arrive at the FDO. in this >> >> case,
>> >> it
>> >> has
>> >> not yet arrived. if it has not yet arrived that means that either
>> >> somebody
>> >> did not call PoStartNextPowerIrp on their device object or another
>> >> device
>> >> object in the stack is still holding onto the Dx irp. I am >> >> guessing
>> >> it
>> >> is
>> >> the latter. what does the device stack look like for the FDO? >> >> Send
>> >> the
>> >> output of !devstack <your device object> and then the output of >> >> !podev
>> >> <devobj> for each device object listed in the output of !devstack.
>> >>
>> >> 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.
>> >>
>> >>
>> >> "DaveH" <DaveH@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> >> news:97E85E66-0174-42B5-B19A-7C7E0438F9A8@xxxxxxxxxxxxxxxx
>> >> > Hi,
>> >> >
>> >> > I have a problem with a KMDF bus driver where the bus driver does
>> >> > not
>> >> > transition its stack back to D0 upon receiving a request on its >> >> > PDOs
>> >> > to
>> >> > transition to D0 as a result of system entering S0. This problem
>> >> > happens
>> >> > intermittently, only on some hosts and mainly on Vista >> >> > (occasionally
>> >> > seen
>> >> > on
>> >> > Win2k and XP).
>> >> >
>> >> > This is the scenario: host is put in S1 state and awoken after >> >> > 20s
>> >> > (using
>> >> > WDTF) and this cycles through. After few cycles, screen comes up >> >> > as
>> >> > either
>> >> > blank or blank with the mouse pointer frozen. System is not
>> >> > responsive
>> >> > and
>> >> > has to be cold-restarted. If I break into the debugger at this >> >> > time,
>> >> > stack
>> >> > backtrace shows CPUs (multiprocessor system) are idle and there
>> >> > doesn't
>> >> > seem
>> >> > to be any deadlocks.
>> >> >
>> >> > There are several power IRPs active in the system at this point, >> >> > the
>> >> > ones
>> >> > of
>> >> > my interest being child FDOs' SET_POWER S0s being pended on
>> >> > SET_POWER
>> >> > D0s
>> >> > it
>> >> > had sent. SET_POWER D0s are then pending in the bus driver for
>> >> > unknown
>> >> > reason. Looking at the KMDF logs, I can see that PDOs have >> >> > received
>> >> > the
>> >> > SET_POWER D0 IRP, but for some reason they are waiting for the
>> >> > parent
>> >> > transition to D0 which never seems to happen.
>> >> >
>> >> > I have included the results of !WDFDEVICE for child PDO and >> >> > parent
>> >> > bus
>> >> > FDO
>> >> > as well as last bits of KMDF logs.
>> >> >
>> >> > Could this be due to a potential race condition in the Framework >> >> > as
>> >> > problem
>> >> > seems to occur more frequently when the number of childs is
>> >> > increased?
>> >> > As
>> >> > power mangement is handled by the Framework, I couldn't think of >> >> > a
>> >> > way
>> >> > to
>> >> > take this any further. What else would you recommend to gather >> >> > more
>> >> > information on this?
>> >> >
>> >> > Many thanks,
>> >> > DaveH
>> >> >
>> >> >
>> >> > //////////////////////// Child PDO
>> >> >
>> >> > 1: kd> !wdfdevice 0x77bf6900 fff
>> >> >
.
- References:
- PM IRPs won't complete in KMDF bus driver
- From: DaveH
- Re: PM IRPs won't complete in KMDF bus driver
- From: Doron Holan [MSFT]
- Re: PM IRPs won't complete in KMDF bus driver
- From: DaveH
- Re: PM IRPs won't complete in KMDF bus driver
- From: Doron Holan [MSFT]
- Re: PM IRPs won't complete in KMDF bus driver
- From: DaveH
- Re: PM IRPs won't complete in KMDF bus driver
- From: Doron Holan [MSFT]
- Re: PM IRPs won't complete in KMDF bus driver
- From: DaveH
- PM IRPs won't complete in KMDF bus driver
- Prev by Date: Re: PM IRPs won't complete in KMDF bus driver
- Next by Date: VIA OHCI Compliant IEEE 1394 Host Controller
- Previous by thread: Re: PM IRPs won't complete in KMDF bus driver
- Next by thread: Re: How do you make a WDF driver create .Raw & .Translated resources?
- Index(es):
Relevant Pages
|
