Skip to main content

 none
Why my ACPI driver need to test "PCI Root Port Surprise Remove Test (PCI devices only)" in Windows 8 HCK and failed? RRS feed

  • Question

  • Hi, all,

    I have a ACPI logic device (not actual hard device) which provide some methods. I wrote a ACPI PnP WDM driver and expose a control device object for user app's IOCTL communication. But why need to test the case of "PCI Root Port Surprise Remove Test (PCI devices only)".

    This case is failed in the following dump, anyone can help:

    DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

    An attempt was made to access a pageable (or completely invalid) address at an

    interrupt request level (IRQL) that is too high.  This is usually

    caused by drivers using improper addresses.

    If kernel debugger is available get stack backtrace.

    Arguments:

    Arg1: 00000000, memory referenced

    Arg2: 00000002, IRQL

    Arg3: 00000000, value 0 = read operation, 1 = write operation

    Arg4: 8554ac20, address which referenced memory

    Debugging Details:

    -----------------

    READ_ADDRESS:  00000000

     

    CURRENT_IRQL:  2

     

    FAULTING_IP:

    ACPI!ACPIVectorDisable+8

    8554ac20 8b00            mov     eax,dword ptr [eax]

    DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

     

    BUGCHECK_STR:  AV

     

    PROCESS_NAME:  System

     

    TRAP_FRAME:  87509750 -- (.trap 0xffffffff87509750)

    ErrCode = 00000000

    eax=00000000 ebx=00000000 ecx=00000060 edx=00000000 esi=89fbe038 edi=89fbe008

    eip=8554ac20 esp=875097c4 ebp=875097c4 iopl=0         nv up ei pl zr na pe nc

    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246

    ACPI!ACPIVectorDisable+0x8:

    8554ac20 8b00            mov     eax,dword ptr [eax]  ds:0023:00000000=????????

    Resetting default scope

     

    LAST_CONTROL_TRANSFER:  from 81fe1840 to 81f6accc

     

    STACK_TEXT: 

    87509730 81fe1840 0000000a 00000000 00000002 nt!KiBugCheck2

    87509730 8554ac20 0000000a 00000000 00000002 nt!KiTrap0E+0x2c8

    875097c4 85544843 00000000 00000000 85544dbe ACPI!ACPIVectorDisable+0x8

    875097d0 85544dbe 89fbe008 00000001 00000001 ACPI!ACPIEcMaskInterrupt+0x27

    875097e8 855446e4 93877000 89f43474 00000000 ACPI!ACPIEcServiceDevice+0x60

    87509800 85544741 00000001 93879d94 8553a240 ACPI!ACPIEcQueueEcIrp+0xe9

    8750981c 81e2d796 87509850 8552f559 00000001 ACPI!ACPIEcOpRegionHandler+0x2e

    87509850 8552f033 00000001 89f43474 00000040 hal!KfLowerIrql+0x2c

    8750988c 85526aae 93877000 89f42ed0 00000000 ACPI!WriteCookAccess+0x141

    875098b8 85527341 93879f2c 00000000 85554478 ACPI!RunContext+0x65

    875098d0 855270ce 93877000 00000000 00000000 ACPI!InsertReadyQueue+0xb4

    875098e8 85527092 93877000 00000000 c0140006 ACPI!RestartContext+0x2e

    87509908 855276d9 89f432d8 00000000 00000002 ACPI!AsyncEvalObject+0x151

    87509960 85527585 00000000 00000002 875099b0 ACPI!SyncEvalObject+0xf2

    87509988 8556874f 89f432d8 00000000 00000002 ACPI!AMLIEvalNameSpaceObject+0x78

    875099ec 85566e63 89f430cc 89fba7b8 00000000 ACPI!UnRegisterOperationRegionHandler+0xf8

    875099fc 85544b50 89fbe008 00000000 85544b24 ACPI!ACPIEcRemoveOpRegionHandler+0x1a

    87509a08 85544b24 841ab318 841ab4ac 87509a5c ACPI!ACPIEcStopRemoveDeviceCommon+0x1e

    87509a18 85526317 89fba7b8 a0a8ef68 89fba7b8 ACPI!ACPIEcRemoveDevice+0x26

    87509a5c 82305f4b 89fba7b8 a0a8ef68 89fba7b8 ACPI!ACPIDispatchIrp+0x2ff

    87509a7c 81eaba9f 820e00de a0a8effc 87509b20 nt!IovCallDriver+0x2e3

    87509a90 820e00de 89fbc008 89fba7b8 00000002 nt!IofCallDriver+0x62

    87509ac0 8217190a 89fba7b8 87509afc c00000bb nt!IopSynchronousCall+0x9c

    87509b20 81f2a8f1 89fba7b8 00000002 89fbc008 nt!IopRemoveDevice+0xc3

    87509b58 821bf1dc 89fbc008 00000000 89fbc008 nt!PnpRemoveLockedDeviceNode+0x1b3

    87509b78 821bedff 00000002 00000000 00000000 nt!PnpDeleteLockedDeviceNode+0x65

    87509bac 821be6af 89f7c030 8d25e188 00000002 nt!PnpDeleteLockedDeviceNodes+0x66

    87509bdc 821be3f0 9c3836f8 00000000 00000010 nt!PnpDelayedRemoveWorker+0x4b

    87509bf8 81f5aa8f 89f7c030 00000001 8419c418 nt!PnpChainDereferenceComplete+0xdd

    87509c1c 821bebce 8ab2d868 00000011 00000000 nt!PnpIsChainDereferenced+0x67

    87509ccc 820f3d28 00000000 a1e65c38 00000000 nt!PnpProcessQueryRemoveAndEject+0x2f9

    87509cec 820f4069 9ca88928 8204a4b8 84187d40 nt!PnpProcessTargetDeviceEvent+0x75

    87509d1c 81ef4854 9ac1fc38 84187d40 00000000 nt!PnpDeviceEventWorker+0x241

    87509d74 81f37415 00010000 e821036e 00000000 nt!ExpWorkerThread+0x111

    87509db0 81fe3039 81ef4747 00010000 00000000 nt!PspSystemThreadStartup+0x4a

    00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

     

     

    STACK_COMMAND:  kb

     

    FOLLOWUP_IP:

    ACPI!ACPIVectorDisable+8

    8554ac20 8b00            mov     eax,dword ptr [eax]

     

    SYMBOL_STACK_INDEX:  2

     

    SYMBOL_NAME:  ACPI!ACPIVectorDisable+8

     

    FOLLOWUP_NAME:  MachineOwner

     

    MODULE_NAME: ACPI

     

    IMAGE_NAME:  ACPI.sys

     

    DEBUG_FLR_IMAGE_TIMESTAMP:  5010ad0a

     

    BUCKET_ID_FUNC_OFFSET:  8

     

    FAILURE_BUCKET_ID:  AV_VRF_ACPI!ACPIVectorDisable

     

    BUCKET_ID:  AV_VRF_ACPI!ACPIVectorDisable

     

    Followup: MachineOwner

    ---------


    Xyz

    Wednesday, October 10, 2012 2:58 AM

All replies

  • Hi,

    Can you check your embedded controller's (EC) _REG method implementation? It appears that ACPI is running embedded controller's _REG() method with Arg0 == EmbeddedControl, and Arg1 == 0x0 (OFF)  to let firmware know that access to EC opregion is going away. But it appears that the firmware is turning around and doing an EC opregion request in that context, which is not desirable. I’m suspecting the firmware is assuming that the _REG is being called to enable the opregion -- here we are actually trying to disable -- and initiating some actions that require EC access. While ideally we should just fail those calls but in this case it would be better if the firmware checked the opregion paramters and not originate EC access if it is being told that the EC is going away.

    -Murali.

    Tuesday, October 16, 2012 7:08 PM
  • Thanks so much.

    We have updated BIOS just the same as you mentioned. It works.

    Wednesday, February 27, 2013 3:32 AM