EVT_WDF_DEVICE_D0_EXIT handler not being called

NTDEV
1

Hi guys,

I’m tracking down a system shutdown hang, and I have a few questions…

// Background:
// ========
I have a kmdf bus driver which uses all Power Managed Queues. It manages communication with a PCI device. I’m pretty sure that I have registered all of the appropriate Power Event Callbacks. During normal shutdown, the driver enters all of the appropriate power down states, and shuts down properly, even when an app has the driver opened, and the driver is talking w/ the PCI device.

// The Problem:
// =========
However, it seems that if the PowerPC on the PCI card is reset while my driver is communicating with it (via reading/writing of Memory Resource BARs), and then I perform a system shutdown, my bus driver doesn’t shut down and unload properly, thus hanging up the shutdown process. It seems to hang just before D0Exit.

If my driver isn’t talking to the PCI card, then the system shutsdown just fine.

// What I can verify:
// ============
I can see that it invokes my TsiiBusEvtDeviceD0ExitPreIrqsDisabled() and TsiiIrqDisable() handlers, with a previous state of D3Final. However, my TsiiBusEvtDeviceD0Exit() handler is never invoked. Since my TsiiBusEvtDeviceD0Exit() handler is never invoked, the driver will not continue to clean up and unload.

I thought that my KeWaitForMultipleObjects() call might be hanging it up, but I put in a 5 second timeout parameter (which I see works), and that’s not the culprit.

I have also verified that there are no open file refs to the driver from Userland, and all pending IOCTLs are cleaned up (since I’ve registered a CancelPendingOnQueue handler).

I have verified that the PPC comes back up (via a serial connection through PuTTY), and seems to renegotiate the PCI bus resources, but Windows never seems to reconfigure/update the driver resources when this happens, nor invokes any Power callbacks (e.g. surprise removal).

// Questions:
// =======
1.) Why would the framework not invoke my TsiiBusEvtDeviceD0Exit() handler, after it successfully invoked TsiiBusEvtDeviceD0ExitPreIrqsDisabled() and TsiiIrqDisable()?

2.) Why doesn’t Windows recognize that the PPC/PCI card goes away during an entire board reset? I have tried a soft reset (button), and a hard reset (removing power). I have registered a TsiiBusEvtDeviceSurpriseRemoval() handler, but it isn’t getting called when I reset the board (either way).

What am I missing here?

I would appreciate any tips that you experts might have! :slight_smile:

Jason

2

xxxxx@gmail.com wrote:

// Questions:
// =======
2.) Why doesn’t Windows recognize that the PPC/PCI card goes away during an entire board reset? I have tried a soft reset (button), and a hard reset (removing power). I have registered a TsiiBusEvtDeviceSurpriseRemoval() handler, but it isn’t getting called when I reset the board (either way).

Which operating system? PCI devices aren’t supposed to go away, so the
PCI bus driver can’t even detect arrivals and removals, at least through XP.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

For 1), D0Exit should be called, these callbacks (D0ExitPreInterruptsDisabled, EvtinterruptDisable, D0Exit) are invoked in the same function one after the other. Perhaps your EvtInterruptDisable is not actually returning. The best thing to do here is to break in and look at the callstacks (!stacks 2 wdf0100 would give you all stacks where KMDF is on the stack) and see where you are at (you could also just dump the current thread pointer via DbgPrint in your D0ExitPreInterruptsDisabled callback and then run !thread )

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, May 27, 2010 10:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] EVT_WDF_DEVICE_D0_EXIT handler not being called

Hi guys,

I’m tracking down a system shutdown hang, and I have a few questions…

// Background:
// ========
I have a kmdf bus driver which uses all Power Managed Queues. It manages communication with a PCI device. I’m pretty sure that I have registered all of the appropriate Power Event Callbacks. During normal shutdown, the driver enters all of the appropriate power down states, and shuts down properly, even when an app has the driver opened, and the driver is talking w/ the PCI device.

// The Problem:
// =========
However, it seems that if the PowerPC on the PCI card is reset while my driver is communicating with it (via reading/writing of Memory Resource BARs), and then I perform a system shutdown, my bus driver doesn’t shut down and unload properly, thus hanging up the shutdown process. It seems to hang just before D0Exit.

If my driver isn’t talking to the PCI card, then the system shutsdown just fine.

// What I can verify:
// ============
I can see that it invokes my TsiiBusEvtDeviceD0ExitPreIrqsDisabled() and TsiiIrqDisable() handlers, with a previous state of D3Final. However, my TsiiBusEvtDeviceD0Exit() handler is never invoked. Since my TsiiBusEvtDeviceD0Exit() handler is never invoked, the driver will not continue to clean up and unload.

I thought that my KeWaitForMultipleObjects() call might be hanging it up, but I put in a 5 second timeout parameter (which I see works), and that’s not the culprit.

I have also verified that there are no open file refs to the driver from Userland, and all pending IOCTLs are cleaned up (since I’ve registered a CancelPendingOnQueue handler).

I have verified that the PPC comes back up (via a serial connection through PuTTY), and seems to renegotiate the PCI bus resources, but Windows never seems to reconfigure/update the driver resources when this happens, nor invokes any Power callbacks (e.g. surprise removal).

// Questions:
// =======
1.) Why would the framework not invoke my TsiiBusEvtDeviceD0Exit() handler, after it successfully invoked TsiiBusEvtDeviceD0ExitPreIrqsDisabled() and TsiiIrqDisable()?

2.) Why doesn’t Windows recognize that the PPC/PCI card goes away during an entire board reset? I have tried a soft reset (button), and a hard reset (removing power). I have registered a TsiiBusEvtDeviceSurpriseRemoval() handler, but it isn’t getting called when I reset the board (either way).

What am I missing here?

I would appreciate any tips that you experts might have! :slight_smile:

Jason

—
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

4

We’re running on XP Embedded.

I put in a debug statement within the EvtInterruptDisable callback (begin and end), and it looks like it finishes…The only thing after the debug statement is a return of status.

I just left the office for a long weekend, so I’ll break in and watch the stack on Tuesday…

Thanks guys!

jason

5

It looks like it’s stuck attempting to disconnect the interrupt. What would prevent WDF from disconnecting an irq gracefully?

0: kd> !stacks 2 wdf0100
Proc.Thread .Thread Ticks ThreadState Blocker

Max cache size is : 1048576 bytes (0x400 KB)
Total memory in cache : 0 bytes (0 KB)
Number of regions cached: 0
0 full reads broken into 0 partial reads
counts: 0 cached/0 uncached, 0.00% cached
bytes : 0 cached/0 uncached, 0.00% cached
** Prototype PTEs are implicitly decoded
[8a1e99c8 System]
4.000020 8a1e7da8 00005d6 READY nt!KiUnlockDispatcherDatabase+0x9e
nt!KeSetSystemAffinityThread+0x5b
nt!KeDisconnectInterrupt+0x1b
nt!IoDisconnectInterrupt+0x26
wdf01000!FxInterrupt::Disconnect+0xf7
wdf01000!FxPkgPnp::NotifyResourceObjectsDx+0x30
wdf01000!FxPkgPnp::PowerGotoDxIoStopped+0xae
wdf01000!FxPkgPnp::PowerGotoDNotZeroIoStopped+0xd
wdf01000!FxPkgPnp::PowerEnterNewState+0x11c
wdf01000!FxPkgPnp::PowerProcessEventInner+0x171
wdf01000!FxPkgPnp::PowerProcessEvent+0x15c
wdf01000!FxPkgPnp::PowerPolTimerExpiredWakeCompletedPowerDown+0x12
wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x11c
wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x185
wdf01000!FxPkgPnp::PowerPolicyProcessEvent+0x172
wdf01000!FxPkgFdo::_SystemPowerSxCompletion+0x11
nt!IopUnloadSafeCompletion+0x1d
nt!IopfCompleteRequest+0xa2
pci!PciDispatchIrp+0xea
nt!IopfCallDriver+0x31
nt!PopPresentIrp+0x57
nt!PoCallDriver+0x195
wdf01000!FxPkgFdo::DispatchSystemSetPower+0x109
wdf01000!FxPkgFdo::_DispatchSetPower+0x1c
wdf01000!FxPkgPnp::Dispatch+0x207
wdf01000!FxDevice::Dispatch+0x7f
wdf01000!FxDevice::DispatchWithLock+0x7b
nt!IopfCallDriver+0x31
nt!PopPresentIrp+0x57
nt!PoCallDriver+0x195
nt!PopNotifyDevice+0x1ac
nt!PopSleepDeviceList+0xb5
nt!PopSetDevicesSystemState+0x1a1
nt!PopGracefulShutdown+0x12c
nt!ExpWorkerThread+0xef
nt!PspSystemThreadStartup+0x34
nt!KiThreadStartup+0x16
4.000034 8a1e6020 000072c Blocked nt!KiSwapContext+0x2f
nt!KiSwapThread+0x8a
nt!KeWaitForSingleObject+0x1c2
wdf01000!FxWaitLockInternal::AcquireLock+0x3a
wdf01000!FxPkgPnp::_PowerPolicyProcessEventInner+0x1c
wdf01000!FxEventQueue::EventQueueWorker+0x6f
wdf01000!FxThreadedEventQueue::_WorkItemCallback+0xd
nt!IopProcessWorkItem+0x13
nt!ExpWorkerThread+0xef
nt!PspSystemThreadStartup+0x34
nt!KiThreadStartup+0x16
*** ERROR: Module load completed but symbols could not be loaded for iaStor.sys
*** ERROR: Module load completed but symbols could not be loaded for nv4_mini.sys

[83288020 smss.exe]

*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
[83246020 csrss.exe]

[83306020 winlogon.exe]

[891551d8 services.exe]

[8a102be8 lsass.exe]

[8a107da0 svchost.exe]

[831cc868 svchost.exe]

[831d9b28 svchost.exe]

[830a78e8 svchost.exe]

[8a0f6690 svchost.exe]

[8327b020 DUAgent.exe]

[83081d60 FreeSSHDService]

[83108020 snmp.exe]

[830e2b28 IAANTmon.exe]

[830095f0 alg.exe]

[830146d0 csrss.exe]

[831c0c88 WmiPrvSE.exe]

[82fb5b28 testApp.exe]
c50.000c54 82fb58b0 000072a RUNNING hal!KfReleaseSpinLock+0x1a
wdf01000!FxSpinLock::ReleaseLock+0xf6
wdf01000!imp_WdfSpinLockRelease+0xac
TSII_BUS!WdfSpinLockRelease+0x16
TSII_BUS!BlenderClose+0xb7
TSII_BUS!TsiiBusEvtFileCleanup+0x57
wdf01000!FxFileObjectFileClose::Invoke+0x24
wdf01000!FxPkgGeneral::OnCleanup+0x6f
wdf01000!FxPkgGeneral::Dispatch+0xa2
wdf01000!FxDevice::Dispatch+0x7f
nt!IopfCallDriver+0x31
nt!IopCloseFile+0x26b
nt!ObpDecrementHandleCount+0xd8
nt!ObpCloseHandleTableEntry+0x14d
nt!ObpCloseHandleProcedure+0x1f
nt!ExSweepHandleTable+0x3b
nt!ObKillProcess+0x5c
nt!PspExitThread+0x5e9
nt!PsExitSpecialApc+0x22
nt!KiDeliverApc+0x1af
nt!KiServiceExit+0x59
ntdll+0xe514

Threads Processed: 268

Max cache size is : 1048576 bytes (0x400 KB)
Total memory in cache : 0 bytes (0 KB)
Number of regions cached: 0
0 full reads broken into 0 partial reads
counts: 0 cached/0 uncached, 0.00% cached
bytes : 0 cached/0 uncached, 0.00% cached
** Transition PTEs are implicitly decoded
** Prototype PTEs are implicitly decoded

6

Here’s what I’m doing in my Irq Disable () callback:

#pragma LOCKEDCODE
NTSTATUS
TsiiIrqDisable(WDFINTERRUPT irq, WDFDEVICE device)
{
PULONG irqMask;

DbgPrint(“TS_II_BUS: TsiiIrqDisable\n”);
irqMask = (PULONG)((ULONG)gPdx->i2oBaseAddress + I2O_HOST_IRQ_MASK);
WRITE_REGISTER_ULONG(irqMask, I2O_HOST_IBDB_IRQ_DISABLE);
DbgPrint(“TS_II_BUS: TsiiIrqDisable Done\n”);

gPdx->DebugIsrFlag = true;

return STATUS_SUCCESS;
}

and here’s the debug output that prints from this:

TS_II_BUS: TsiiBusEvtDeviceD0ExitPreIrqsDisabled()
previous power state: D3Final

TS_II_BUS: TsiiIrqDisable
TS_II_BUS: TsiiIrqDisable Done

So, it *seems* to finish this callback…

However, since the PCI device has been reset, what happens to all of the BAR memory resources that were previously mapped (and which I’m attempting to write to to turn off irqs)? Is this part of my problem? How do I get notified that these resources have gone away, other than by a suprise removal notification?

Jason

7

Per Doron’s blog:

http://blogs.msdn.com/b/doronh/archive/2006/03/17/554179.aspx

I ran !poaction, !poreqlist, and !podev:

0: kd> !podev 8a101ad8
Device object is for:
DriverObject 89162420
Current Irp 00000000 RefCount 1 Type 00000022 DevFlags 00002050 DO_POWER_PAGABLE
Device queue is not busy.
Device Object Extension: 8a101ba8:
PowerFlags: 00000516 =>SystemState=6 DeviceState=1 syact dvact
Dope: 00000000:

0: kd> !poreqlist
All active Power Irps from PoRequestPowerIrp
PopReqestedPowerIrpList
FieldOffset = 00000004
Irp 83fc7c08 DevObj 83f29030 \Driver\usbuhci Ctx 00000002 Wait Wake S1
Irp 83237008 DevObj 83f20030 \Driver\usbuhci Ctx 00000002 Wait Wake S1
Irp 833174f0 DevObj 83ed6030 \Driver\usbuhci Ctx 00000002 Wait Wake S1
Irp 8331c710 DevObj 83367030 \Driver\usbuhci Ctx 00000002 Wait Wake S1
Irp 83277e70 DevObj 83ed4030 \Driver\usbehci Ctx 00000002 Wait Wake S1
Irp 8325ce70 DevObj 83316030 \Driver\usbehci Ctx 00000002 Wait Wake S1
Irp 83319990 DevObj 83376030 \Driver\usbuhci Ctx 00000002 Wait Wake S1
Irp 831430d0 DevObj 8413e720 \Driver\HDAudBus Ctx 00000003 Set Power D3 ShutdownType 5
Irp 83237950 DevObj 8a101ad8 \Driver\TS_II_BUS Ctx 00000003 Set Power D3 ShutdownType 5

You can see that my driver TS_II_BUS is in the “Set Power D3 ShutdownType 5” state…

0: kd> !poaction
PopAction: 8055c418
State…: 3 - Set System State
Updates…: 0 SHUTDOWN-set
Action…: ShutdownReset
Lightest State.: Shutdown
Flags…: c0000004 OverrideApps|DisableWakes|Critical
Irp minor…: SetPower
System State…: Shutdown
Hiber Context…: 00000000

Device State 82fcc9e0
Irp minor…: SetPower
System State…: Shutdown
Worker thread…: 8a1e7da8
Status…: 0
Waking…: FALSE
Cancelled…: FALSE
Ignore errors…: TRUE
Ignore not imp.: TRUE
Wait any…: FALSE
Wait all…: FALSE
Present Irp Q…: Head:82fccc5c Empty

Order:
Level 7 (82fccc04) 0/20 Paged, Root-Enum
Level 5 (82fccb74) 4/32 Paged, PnP
ReadySleep:
831d74b8: 8a1f97f0 \Driver\HDAudBus
831023d0: 83fc1ae0 \Driver\usbhub \Device\00000080
Level 4 (82fccb2c) 0/2 Paged, PnP, Video
WaitSleep:
830b9ea8: 8a17c1f0 \Driver\nv \Device\Video0
ReadySleep:
831dbae8: 831fb008 \Driver\nv \Device\VideoPdo0
Level 3 (82fccae4) 0/46 Non-Paged, Root-Enum
WaitSleep:
8320a348: 8a1ff008 \Driver\Ftdisk \Device\FtControl
ReadySleep:
8309a038: 8a1cf358 \Driver\dmio \Device\DmControl\DmPnP
83120868: 8a126a08 \Driver\Ftdisk \Device\HarddiskVolume2
83c7d068: 8a126b28 \Driver\Ftdisk \Device\HarddiskVolume1
830b15d8: 8a1ffd90 \Driver\PnpManager \Device\00000005
83078fd8: 8a1ffb10 \Driver\PnpManager \Device\00000006
830fa380: 8a1ff8d0 \Driver\PnpManager \Device\00000007
831da760: 8a1ff690 \Driver\PnpManager \Device\00000008
830dffb0: 8a1ff328 \Driver\PnpManager \Device\00000009
83011fd8: 8a1ce008 \Driver\PnpManager \Device\0000000a
830a54a0: 8a1cedc8 \Driver\PnpManager \Device\0000000b
8310d0b0: 8a1ceb88 \Driver\PnpManager \Device\0000000c
83049258: 8a1ce948 \Driver\PnpManager \Device\0000000d
8a1180c0: 8a1ce708 \Driver\PnpManager \Device\0000000e
831376b0: 8a1ce4c8 \Driver\PnpManager \Device\0000000f
831db0d0: 8a1ce288 \Driver\PnpManager \Device\00000010
8a116678: 8a1fe008 \Driver\PnpManager \Device\00000011
8a100778: 8a1fedc8 \Driver\PnpManager \Device\00000012
83012678: 8a1feb88 \Driver\PnpManager \Device\00000013
83029720: 8a1fe948 \Driver\PnpManager \Device\00000014
83039558: 8a1fe708 \Driver\PnpManager \Device\00000015
83034180: 8a1fe4c8 \Driver\PnpManager \Device\00000016
89159478: 8a1fe288 \Driver\PnpManager \Device\00000017
8315c008: 8a1cd008 \Driver\PnpManager \Device\00000018
831381f8: 8a1cddc8 \Driver\PnpManager \Device\00000019
830368e0: 8a1cdb88 \Driver\PnpManager \Device\0000001a
83076468: 8a1cd948 \Driver\PnpManager \Device\0000001b
83142008: 8a1cd708 \Driver\PnpManager \Device\0000001c
82ffba08: 8a1cd4c8 \Driver\PnpManager \Device\0000001d
83260660: 8a1cd288 \Driver\PnpManager \Device\0000001e
82ff41c8: 8a1fd008 \Driver\PnpManager \Device\0000001f
830d84f8: 8a1fddc8 \Driver\PnpManager \Device\00000020
83044a90: 8a1fdb88 \Driver\PnpManager \Device\00000021
83077b60: 8a1fd948 \Driver\PnpManager \Device\00000022
83015d68: 8a1fd708 \Driver\PnpManager \Device\00000023
830751c8: 8a1fd4c8 \Driver\PnpManager \Device\00000024
830495f0: 8a1fd288 \Driver\PnpManager \Device\00000025
831e0170: 8a1cc008 \Driver\PnpManager \Device\00000026
891510d8: 8a1ccdc8 \Driver\PnpManager \Device\00000027
830512d8: 8a1ccb88 \Driver\PnpManager \Device\00000028
830dc928: 8a1cc948 \Driver\PnpManager \Device\00000029
83102980: 8a1cc708 \Driver\PnpManager \Device\0000002a
830ba6b0: 8a1cc4c8 \Driver\PnpManager \Device\0000002b
831198b0: 8a1cc288 \Driver\PnpManager \Device\0000002c
831e3898: 8a1fbdc8 \Driver\rdpdr \Device\RdpDrDvMgr
830195b0: 8a1fb288 \Driver\mssmbios
Level 1 (82fcca54) 0/49 Non-Paged, PnP
WaitSleep:
83119378: 8a1cf598 \Driver\ACPI_HAL
83073e70: 8a1f8b48 \Driver\ACPI
83096c60: 8a1ea9f0 \Driver\pci
8311d978: 8a1ecdc8 \Driver\iaStor \Device\Ide\iaStor0
83160088: 8a1ecee8 \Driver\isapnp
830159d8: 8a1ec008 \Driver\pci
8305f330: 8a1ed828 \Driver\pci
8a0f2158: 8a1ed948 \Driver\pci
830e7b90: 8a1edca8 \Driver\usbuhci \Device\USBFDO-2
83062330: 8a1ee610 \Driver\pci
8305d460: 8a1ee730 \Driver\pci
ReadySleep:
831ef760: 8a1ea570 \Driver\ACPI \Device\00000051
8a0fcae8: 8a1ea690 \Driver\ACPI \Device\00000050
89156ab8: 8a1ea7b0 \Driver\ACPI \Device\0000004f
8327b370: 8a1ea8d0 \Driver\ACPI \Device\0000004e
831d7460: 8a1eca68 \Driver\ACPI \Device\00000053
831d4360: 8a1ecb88 \Driver\WmiAcpi
83119f98: 8a1ecca8 \Driver\ACPI \Device\00000067
8308b0f8: 8a18f2f0 \Driver\PartMgr
830086a8: 8a190008 \Driver\ACPI \Device\00000076
8320af40: 8a16f1c0 \Driver\ACPI \Device\00000075
82fbfe60: 8a16f520 \Driver\ACPI \Device\00000072
830551d0: 8a16f640 \Driver\ACPI \Device\00000071
831c00b8: 8a16f760 \Driver\ACPI \Device\00000070
8a108620: 8a16f008 \Driver\ACPI \Device\0000006f
83055ed8: 8a1fa708 \Driver\ACPI \Device\0000006e
8308e3c8: 8a1fa828 \Driver\ACPI \Device\0000006d
830c1588: 8a1fa948 \Driver\ACPI \Device\0000006c
830393d8: 8a1faa68 \Driver\isapnp \Device\0000006b
83000180: 8a1eb658 \Driver\pci \Device\NTPNP_PCI0026
8305df00: 8a17c4f0 \Driver\JRAID \Device\Scsi\JRAID1
83092d98: 8a191588 \Driver\JRAID \Device\Scsi\JRAID2
83091a58: 8a1ed008 \Driver\pci \Device\NTPNP_PCI0008
831f5f08: 8a1ee190 \Driver\pci \Device\NTPNP_PCI0007
83094738: 8a1ee2b0 \Driver\pci \Device\NTPNP_PCI0006
8311dda0: 8a1ee3d0 \Driver\pci \Device\NTPNP_PCI0005
8311d770: 8a1ee4f0 \Driver\pci
83066550: 8a1ee850 \Driver\pci
83061e30: 8a1ee970 \Driver\pci \Device\NTPNP_PCI0000
8311eed8: 8a1ca1a0 \Driver\ACPI \Device\0000004c
830cc7c0: 8a1ed168 \Driver\usbehci \Device\USBFDO-7
8300e5d8: 8a1ed288 \Driver\usbuhci \Device\USBFDO-6
830d1f10: 8a1ed3a8 \Driver\usbuhci \Device\USBFDO-5
830d0888: 8a1ed4c8 \Driver\usbuhci \Device\USBFDO-4
83305690: 8a1ed5e8 \Driver\pci
83098d38: 8a1ed708 \Driver\pci
832753e0: 8a1edb88 \Driver\usbehci \Device\USBFDO-3
83242760: 8a1eddc8 \Driver\usbuhci \Device\USBFDO-1
8311e330: 8a1edee8 \Driver\usbuhci \Device\USBFDO-0

Pending irps:
Irp: 83018288 Notify 00000000
Irp: 82ff5ae8 Notify 00000000

Completed irps:
Irp: 830dc778 Notify 00000000
Irp: 83ed6e70 Notify 00000000
Irp: 83120660 Notify 00000000
Irp: 82fcb570 Notify 00000000
Irp: 8313e008 Notify 00000000
Irp: 830bc478 Notify 00000000
Irp: 8304d6f8 Notify 00000000
Irp: 830a49c0 Notify 00000000
Irp: 82ff3290 Notify 00000000

I ran this to see that one of the pending irps is related to CompleteSystemPowerIrp.

0: kd> !irp 82ff5ae8
Irp is active with 2 stacks 2 is current (= 0x82ff5b7c)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[16, 0] 0 0 8a1c7bb8 00000000 8050da0a-83042148
\Driver\pci nt!IopUnloadSafeCompletion
Args: 00000000 00000000 00000000 00000000

[16, 2] 0 e1 8a101ad8 00000000 8066ffda-82fcce48 Success Error Cancel pending
\Driver\TS_II_BUS nt!PopCompleteSystemPowerIrp
Args: 00000000 00000000 00000006 00000005

So, it looks like it’s waiting on the CompleteSystemPowerIrp IRP to be completed by the PCI driver? Is this because the device has been reset, and the PCI driver can’t talk to it? If so, is this ever recoverable? This seems to be a blocking irp, and I guess uncancellable? How will I be able to recover without making someone to and push the reset button (least desireable solution).

Any ideas anyone? :slight_smile:

Thanks!

Jason

8

Are you messing with interrupt affinity in any way when creating the WDFINTERRUPT or in the INF?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, June 02, 2010 10:24 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] EVT_WDF_DEVICE_D0_EXIT handler not being called

Here’s what I’m doing in my Irq Disable () callback:

#pragma LOCKEDCODE
NTSTATUS
TsiiIrqDisable(WDFINTERRUPT irq, WDFDEVICE device) {
PULONG irqMask;

DbgPrint(“TS_II_BUS: TsiiIrqDisable\n”);
irqMask = (PULONG)((ULONG)gPdx->i2oBaseAddress + I2O_HOST_IRQ_MASK);
WRITE_REGISTER_ULONG(irqMask, I2O_HOST_IBDB_IRQ_DISABLE);
DbgPrint(“TS_II_BUS: TsiiIrqDisable Done\n”);

gPdx->DebugIsrFlag = true;

return STATUS_SUCCESS;
}

and here’s the debug output that prints from this:

TS_II_BUS: TsiiBusEvtDeviceD0ExitPreIrqsDisabled()
previous power state: D3Final

TS_II_BUS: TsiiIrqDisable
TS_II_BUS: TsiiIrqDisable Done

So, it *seems* to finish this callback…

However, since the PCI device has been reset, what happens to all of the BAR memory resources that were previously mapped (and which I’m attempting to write to to turn off irqs)? Is this part of my problem? How do I get notified that these resources have gone away, other than by a suprise removal notification?

Jason

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

9

No, not really. I’m doing this in my EvtDevicePrepareHardware() callback:

…
PCM_PARTIAL_RESOURCE_DESCRIPTOR desc;
…
case CmResourceTypeInterrupt:

if (desc->Flags & CM_RESOURCE_INTERRUPT_MESSAGE)
{
DbgPrint(“Messaging IRQ - Not Supported by this driver…yet!\n”);
}
else
{
// Save the IRQ properties in the device extension:
gPdx->irqVector = desc->u.Interrupt.Vector;
gPdx->irqLevel = (KIRQL)desc->u.Interrupt.Level;
gPdx->irqAffinity = desc->u.Interrupt.Affinity;

gotIrqResource = TRUE;
}

break;
…

and this within DeviceAdd():

// =======================
// Initialize IRQ handlers
// =======================
WDF_INTERRUPT_CONFIG_INIT(&irqCfg, TsiiIsr, TsiiDpc);
irqCfg.EvtInterruptEnable = TsiiIrqEnable;
irqCfg.EvtInterruptDisable = TsiiIrqDisable;
status = WdfInterruptCreate(hDevice, &irqCfg, WDF_NO_OBJECT_ATTRIBUTES, &gPdx->wdfIrq);

if (!NT_SUCCESS (status))
{
DbgPrint(“WdfInterruptCreate failed 0x%0x\n”, status);
return status;
}

Those are the only locations where I use the irq affinity. I double checked my INF file, and I’m not mucking with it in their either.

Hmmm…what else can I do to track this problem down?

10

Okay, this bus driver creates a PDO, for which I install my ndis driver to…I’m thinking the NDIS driver shutdown (or improper shutdown rather) is the culprit here…Let me do some research!

Thanks!

Jason

11

It looks like my NDIS driver is getting cleaned up just fine. MPShutdown() is called, and I don’t see any open refs to the device. To prove that the NDIS driver isn’t the problem, I disabled it, and reran the pci card reset test. I’m seeing the same hanging results as before.

I think you’re on to something Doron with respect to the irq. Any suggestions for moving forward would be great! :slight_smile: I’ll keep looking on my side while I wait for other suggestions.

Thanks!

Jason

12

Look at all other active threads on all other procs. The disconnect call could be stuck trying to sync with another proc

d

sent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@gmail.com
Sent: June 03, 2010 7:54 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] EVT_WDF_DEVICE_D0_EXIT handler not being called

It looks like my NDIS driver is getting cleaned up just fine. MPShutdown() is called, and I don’t see any open refs to the device. To prove that the NDIS driver isn’t the problem, I disabled it, and reran the pci card reset test. I’m seeing the same hanging results as before.

I think you’re on to something Doron with respect to the irq. Any suggestions for moving forward would be great! :slight_smile: I’ll keep looking on my side while I wait for other suggestions.

Thanks!

Jason

—
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

13

Found the bug…

Going on Doron’s last suggestion, I started looking at various processes and threads that were running during shutdown. I saw (unexpectedly) where my test app that was talking to the driver hadn’t totally shut down because it was waiting on a queue of frames to empty down in the bus driver (which never happens because the PCI card was reset, and frames can’t be sent down any longer). I thought it had shut down because the window went away! But the debugger showe me otherwise! LoL

Thanks as always Doron…I learned yet a few more useful debugging techniques! :slight_smile:

Best Regards,

Jason

14

Glad you found the problem

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, June 03, 2010 10:46 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] EVT_WDF_DEVICE_D0_EXIT handler not being called

Found the bug…

Going on Doron’s last suggestion, I started looking at various processes and threads that were running during shutdown. I saw (unexpectedly) where my test app that was talking to the driver hadn’t totally shut down because it was waiting on a queue of frames to empty down in the bus driver (which never happens because the PCI card was reset, and frames can’t be sent down any longer). I thought it had shut down because the window went away! But the debugger showe me otherwise! LoL

Thanks as always Doron…I learned yet a few more useful debugging techniques! :slight_smile:

Best Regards,

Jason

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