Hi All,
I have a buggy PCI board that disables its BAR registers on some internal
conditions.
The device is used by my driver in PIO mode. It includes the config memory
space, the data space and uses the interrupt.
In some circumstances the device restarts its firmware and the PCI memory
spaces become unavailable returning 0xffffffff for any read attempt.
To restore settings I use a timer DPC that periodically tries to read a
DWORD from the device's config space and if 0xffffffff returned, it starts
the restore sequence.
In the routine I use IoInvalidateDeviceState() to ask the system send the
driver IRP_MJ_PNP -> IRP_MN_QUERY_PNP_DEVICE_STATE.
In answer to the IRP I set
pIrp->IoStatus.Information |=
PNP_DEVICE_FAILED | PNP_DEVICE_RESOURCE_REQUIREMENTS_CHANGED;
pIrp->IoStatus.Status = STATUS_SUCCESS;
and pass the IRP down to the bus driver.
After that the system sends me IRP_MN_QUERY_STOP_DEVICE and
IRP_MN_STOP_DEVICE, where I unmap the memory spaces and deregister the
Interrupt.
After that the system send IRP_MN_START_DEVICE where I do the same as on the
driver start (map memory, connect the interrupt).
After that all seems to work, but when my driver starts communicate with the
device and receive interrupts the system crashes with the following error:
Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000
PROCESS_NAME: winlogon.exe
FAULTING_IP:
+8244c8b
08244c8b ?? ???
EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 08244c8b
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000008
Parameter[1]: 08244c8b
Attempt to execute non-executable address 08244c8b
ERROR_CODE: (NTSTATUS) 0xc0000005 -
WRITE_ADDRESS: 08244c8b
BUGCHECK_STR: ACCESS_VIOLATION
DEFAULT_BUCKET_ID: DRIVER_FAULT
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from bad36b8d to 08244c8b
STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
b9eaf2ac bad36b8d 85b88320 8731ef20 b9eaf2d4 0x8244c8b
b9eaf2bc babf5d86 85b88320 8731ef20 8731ef20 ks!KsDispatchIrp+0xa5
b9eaf2d4 babf63d6 85b88320 8731ef20 b9eaf304 portcls!KsoDispatchIrp+0x43
b9eaf2e4 bac05df7 85b88320 8731ef20 80a56be4 portcls!PcDispatchIrp+0x2d
b9eaf304 809b450c 85b88320 8731ef20 b9eaf398 ALCXWDM+0xdf7
b9eaf334 8081dcb3 babb094c b9eaf50c babb094c nt!IovCallDriver+0x112
b9eaf340 babb094c 8513a2cc 8513a238 8513a238 nt!IofCallDriver+0x13
b9eaf5c4 babb4a2b 8737cf00 b9eaf61c 00000000 ALCXSENS+0x4b94c
b9eaf5d8 babb5674 8737cf00 80a56be4 85b88200 ALCXSENS+0x4fa2b
b9eaf5ec 809b450c 85b88200 8737cf00 85140e68 ALCXSENS+0x50674
b9eaf61c 8081dcb3 808f8255 b9eaf710 808f8255 nt!IovCallDriver+0x112
b9eaf628 808f8255 b9eaf7d0 866242b0 00000000 nt!IofCallDriver+0x13
b9eaf710 80936af5 866242c8 00000000 8513b950 nt!IopParseDevice+0xa35
b9eaf790 80932de6 00000000 b9eaf7d0 00000240 nt!ObpLookupObjectName+0x5a9
b9eaf7e4 808ea211 00000000 00000000 9bcde700 nt!ObOpenObjectByName+0xea
b9eaf860 808eb4ab e1644d20 c0000000 b9eaf9d4 nt!IopCreateFile+0x447
b9eaf8bc 808edf2a e1644d20 c0000000 b9eaf9d4 nt!IoCreateFile+0xa3
b9eaf8fc 80888c6c e1644d20 c0000000 b9eaf9d4 nt!NtCreateFile+0x30
b9eaf8fc 8082e105 e1644d20 c0000000 b9eaf9d4 nt!KiFastCallEntry+0xfc
b9eaf9a0 b9de0375 e1644d20 c0000000 b9eaf9d4 nt!ZwCreateFile+0x11
b9eaf9fc b9ddf555 e22b0e30 e1644d20 00000004 sysaudio!OpenDevice+0x56
b9eafa18 b9de6015 b9eafa54 e22a9868 800007a4
sysaudio!CFilterNodeInstance::Create+0x69
b9eafa58 b9de5ff0 00000001 00000001 85503b68
sysaudio!CDeviceNode::SetPreferredStatus+0x18
b9eafa70 bad3646b 86c80e90 e22ac810 85503b60
sysaudio!SetPreferredDevice+0xb6
b9eafad4 bad36299 86c80e90 00000004 b9ddc650 ks!KspPropertyHandler+0x616
b9eafaf8 b9ddea6e 86c80e90 00000004 b9ddc628 ks!KsPropertyHandler+0x19
b9eafb1c bad364a5 e22936a8 85503b68 b9eafb5c
sysaudio!CFilterInstance::FilterDispatchIoControl+0x12a
b9eafb2c 809b450c 854fda08 86c80e90 8513af90 ks!DispatchDeviceIoControl+0x28
b9eafb5c 8081dcb3 bad36334 b9eafb94 bad36334 nt!IovCallDriver+0x112
b9eafb68 bad36334 bad362a9 002f0003 8589a000 nt!IofCallDriver+0x13
b9eafb94 b9dfad19 8513af90 00000000 002f0003
ks!KsSynchronousIoControlDevice+0xbd
b9eafbec b9dfa1ff 00000000 8513ba30 8584f020 wdmaud!SetPreferredDevice+0xfa
b9eafc10 809b450c 00000000 8589a000 873f8f48 wdmaud!SoundDispatch+0x1e5
b9eafc40 8081dcb3 808f4797 b9eafc60 808f4797 nt!IovCallDriver+0x112
b9eafc4c 808f4797 873f8fdc 855305c0 873f8f48 nt!IofCallDriver+0x13
b9eafc60 808f5515 8584f020 873f8f48 855305c0
nt!IopSynchronousServiceTail+0x10b
b9eafd00 808ee0e4 00000840 00000864 00000000 nt!IopXxxControlFile+0x5db
b9eafd34 80888c6c 00000840 00000864 00000000 nt!NtDeviceIoControlFile+0x2a
b9eafd34 7c82ed54 00000840 00000864 00000000 nt!KiFastCallEntry+0xfc
011cfd90 7c8213e4 77e41788 00000840 00000864 ntdll!KiFastSystemCallRet
011cfd94 77e41788 00000840 00000864 00000000 ntdll!NtDeviceIoControlFile+0xc
011cfdf8 72d74543 00000840 001d8028 00a8fac0 kernel32!DeviceIoControl+0xd2
011cfe40 72d71565 00a8fac0 00000000 00000000
wdmaud_72d70000!wdmaudIoControl+0x96
011cfe60 72d71abf 00000001 00000000 00000000
wdmaud_72d70000!wdmaudSetPreferredDevice+0x3b
011cfe84 76aa4e0a 00000000 00000015 00000000 wdmaud_72d70000!wodMessage+0x84
011cfea8 76aa4c9f 76ac0560 00000000 00000000 WINMM!AudioSrvBinding+0x31
011cfec8 76aa9f64 00000000 00000015 00000000 WINMM!RegQuerySzValue+0x95
011cff04 76aa64fc 00070000 00000000 00a99d28 WINMM!DllInstanceInit+0xa1
011cffa0 80a5762d 011cffdc 0103db62 01014998 WINMM!mixerOpen+0x157
011cffa0 00000000 011cffdc 0103db62 01014998 hal!HalpApcInterrupt+0xcd
STACK_COMMAND: kb
FOLLOWUP_IP:
ks!KsDispatchIrp+a5
bad36b8d ebf2 jmp ks!KsDispatchIrp+0x126 (bad36b81)
FAULTING_SOURCE_CODE:
SYMBOL_STACK_INDEX: 1
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: ks!KsDispatchIrp+a5
MODULE_NAME: ks
IMAGE_NAME: ks.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 42435e1f
FAILURE_BUCKET_ID: ACCESS_VIOLATION_W_VRF_ks!KsDispatchIrp+a5
BUCKET_ID: ACCESS_VIOLATION_W_VRF_ks!KsDispatchIrp+a5
-----------------------------------
This bugcheck seems to have nothing to do with my driver, but it obviously
is related to the stop/start sequence it did.
The most interesting thing is it always points to WRITE_ADDRESS: 08244c8b
This address is reported every time in Windows 2003 SP1 x86 and Windows XP
SP2 x86.
So I suspect the method I currently use is not the right one.
Maybe there is another method of doing the same that I could use?
Thank you in advance for any help.
Best regards,
Valeriy Glushkov
Can you just keep a copy of your config space settings and rewrite it
after detecting the reset? Seems like it might be easier. I hope
they are going to fix that hardware before you ship. My pet peeve is
hardware engineers tossing issues over the fence to the poor software guy.
-z
At 04:11 AM 10/14/2006, you wrote:
Hi All,
I have a buggy PCI board that disables its BAR registers on some
internal conditions.
The device is used by my driver in PIO mode. It includes the config
memory space, the data space and uses the interrupt.
In some circumstances the device restarts its firmware and the PCI
memory spaces become unavailable returning 0xffffffff for any read attempt.
To restore settings I use a timer DPC that periodically tries to
read a DWORD from the device’s config space and if 0xffffffff
returned, it starts the restore sequence.
In the routine I use IoInvalidateDeviceState() to ask the system
send the driver IRP_MJ_PNP -> IRP_MN_QUERY_PNP_DEVICE_STATE.
In answer to the IRP I set
pIrp->IoStatus.Information |=
PNP_DEVICE_FAILED | PNP_DEVICE_RESOURCE_REQUIREMENTS_CHANGED;
pIrp->IoStatus.Status = STATUS_SUCCESS;
and pass the IRP down to the bus driver.
After that the system sends me IRP_MN_QUERY_STOP_DEVICE and
IRP_MN_STOP_DEVICE, where I unmap the memory spaces and
deregister the Interrupt.
After that the system send IRP_MN_START_DEVICE where I do the same
as on the driver start (map memory, connect the interrupt).
After that all seems to work, but when my driver starts communicate
with the device and receive interrupts the system crashes with the
following error:
Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000
PROCESS_NAME: winlogon.exe
FAULTING_IP:
+8244c8b
08244c8b ?? ???
EXCEPTION_RECORD: ffffffff – (.exr ffffffffffffffff)
ExceptionAddress: 08244c8b
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000008
Parameter[1]: 08244c8b
Attempt to execute non-executable address 08244c8b
ERROR_CODE: (NTSTATUS) 0xc0000005 -
>
>WRITE_ADDRESS: 08244c8b
>
>BUGCHECK_STR: ACCESS_VIOLATION
>
>DEFAULT_BUCKET_ID: DRIVER_FAULT
>
>CURRENT_IRQL: 0
>
>LAST_CONTROL_TRANSFER: from bad36b8d to 08244c8b
>
>STACK_TEXT:
>WARNING: Frame IP not in any known module. Following frames may be wrong.
>b9eaf2ac bad36b8d 85b88320 8731ef20 b9eaf2d4 0x8244c8b
>b9eaf2bc babf5d86 85b88320 8731ef20 8731ef20 ks!KsDispatchIrp+0xa5
>b9eaf2d4 babf63d6 85b88320 8731ef20 b9eaf304 portcls!KsoDispatchIrp+0x43
>b9eaf2e4 bac05df7 85b88320 8731ef20 80a56be4 portcls!PcDispatchIrp+0x2d
>b9eaf304 809b450c 85b88320 8731ef20 b9eaf398 ALCXWDM+0xdf7
>b9eaf334 8081dcb3 babb094c b9eaf50c babb094c nt!IovCallDriver+0x112
>b9eaf340 babb094c 8513a2cc 8513a238 8513a238 nt!IofCallDriver+0x13
>b9eaf5c4 babb4a2b 8737cf00 b9eaf61c 00000000 ALCXSENS+0x4b94c
>b9eaf5d8 babb5674 8737cf00 80a56be4 85b88200 ALCXSENS+0x4fa2b
>b9eaf5ec 809b450c 85b88200 8737cf00 85140e68 ALCXSENS+0x50674
>b9eaf61c 8081dcb3 808f8255 b9eaf710 808f8255 nt!IovCallDriver+0x112
>b9eaf628 808f8255 b9eaf7d0 866242b0 00000000 nt!IofCallDriver+0x13
>b9eaf710 80936af5 866242c8 00000000 8513b950 nt!IopParseDevice+0xa35
>b9eaf790 80932de6 00000000 b9eaf7d0 00000240 nt!ObpLookupObjectName+0x5a9
>b9eaf7e4 808ea211 00000000 00000000 9bcde700 nt!ObOpenObjectByName+0xea
>b9eaf860 808eb4ab e1644d20 c0000000 b9eaf9d4 nt!IopCreateFile+0x447
>b9eaf8bc 808edf2a e1644d20 c0000000 b9eaf9d4 nt!IoCreateFile+0xa3
>b9eaf8fc 80888c6c e1644d20 c0000000 b9eaf9d4 nt!NtCreateFile+0x30
>b9eaf8fc 8082e105 e1644d20 c0000000 b9eaf9d4 nt!KiFastCallEntry+0xfc
>b9eaf9a0 b9de0375 e1644d20 c0000000 b9eaf9d4 nt!ZwCreateFile+0x11
>b9eaf9fc b9ddf555 e22b0e30 e1644d20 00000004 sysaudio!OpenDevice+0x56
>b9eafa18 b9de6015 b9eafa54 e22a9868 800007a4
>sysaudio!CFilterNodeInstance::Create+0x69
>b9eafa58 b9de5ff0 00000001 00000001 85503b68
>sysaudio!CDeviceNode::SetPreferredStatus+0x18
>b9eafa70 bad3646b 86c80e90 e22ac810 85503b60 sysaudio!SetPreferredDevice+0xb6
>b9eafad4 bad36299 86c80e90 00000004 b9ddc650 ks!KspPropertyHandler+0x616
>b9eafaf8 b9ddea6e 86c80e90 00000004 b9ddc628 ks!KsPropertyHandler+0x19
>b9eafb1c bad364a5 e22936a8 85503b68 b9eafb5c
>sysaudio!CFilterInstance::FilterDispatchIoControl+0x12a
>b9eafb2c 809b450c 854fda08 86c80e90 8513af90 ks!DispatchDeviceIoControl+0x28
>b9eafb5c 8081dcb3 bad36334 b9eafb94 bad36334 nt!IovCallDriver+0x112
>b9eafb68 bad36334 bad362a9 002f0003 8589a000 nt!IofCallDriver+0x13
>b9eafb94 b9dfad19 8513af90 00000000 002f0003
>ks!KsSynchronousIoControlDevice+0xbd
>b9eafbec b9dfa1ff 00000000 8513ba30 8584f020 wdmaud!SetPreferredDevice+0xfa
>b9eafc10 809b450c 00000000 8589a000 873f8f48 wdmaud!SoundDispatch+0x1e5
>b9eafc40 8081dcb3 808f4797 b9eafc60 808f4797 nt!IovCallDriver+0x112
>b9eafc4c 808f4797 873f8fdc 855305c0 873f8f48 nt!IofCallDriver+0x13
>b9eafc60 808f5515 8584f020 873f8f48 855305c0
>nt!IopSynchronousServiceTail+0x10b
>b9eafd00 808ee0e4 00000840 00000864 00000000 nt!IopXxxControlFile+0x5db
>b9eafd34 80888c6c 00000840 00000864 00000000 nt!NtDeviceIoControlFile+0x2a
>b9eafd34 7c82ed54 00000840 00000864 00000000 nt!KiFastCallEntry+0xfc
>011cfd90 7c8213e4 77e41788 00000840 00000864 ntdll!KiFastSystemCallRet
>011cfd94 77e41788 00000840 00000864 00000000 ntdll!NtDeviceIoControlFile+0xc
>011cfdf8 72d74543 00000840 001d8028 00a8fac0 kernel32!DeviceIoControl+0xd2
>011cfe40 72d71565 00a8fac0 00000000 00000000
>wdmaud_72d70000!wdmaudIoControl+0x96
>011cfe60 72d71abf 00000001 00000000 00000000
>wdmaud_72d70000!wdmaudSetPreferredDevice+0x3b
>011cfe84 76aa4e0a 00000000 00000015 00000000 wdmaud_72d70000!wodMessage+0x84
>011cfea8 76aa4c9f 76ac0560 00000000 00000000 WINMM!AudioSrvBinding+0x31
>011cfec8 76aa9f64 00000000 00000015 00000000 WINMM!RegQuerySzValue+0x95
>011cff04 76aa64fc 00070000 00000000 00a99d28 WINMM!DllInstanceInit+0xa1
>011cffa0 80a5762d 011cffdc 0103db62 01014998 WINMM!mixerOpen+0x157
>011cffa0 00000000 011cffdc 0103db62 01014998 hal!HalpApcInterrupt+0xcd
>
>STACK_COMMAND: kb
>
>FOLLOWUP_IP:
>ks!KsDispatchIrp+a5
>bad36b8d ebf2 jmp ks!KsDispatchIrp+0x126 (bad36b81)
>
>FAULTING_SOURCE_CODE:
>
>SYMBOL_STACK_INDEX: 1
>
>FOLLOWUP_NAME: MachineOwner
>
>SYMBOL_NAME: ks!KsDispatchIrp+a5
>
>MODULE_NAME: ks
>
>IMAGE_NAME: ks.sys
>
>DEBUG_FLR_IMAGE_TIMESTAMP: 42435e1f
>
>FAILURE_BUCKET_ID: ACCESS_VIOLATION_W_VRF_ks!KsDispatchIrp+a5
>
>BUCKET_ID: ACCESS_VIOLATION_W_VRF_ks!KsDispatchIrp+a5
>-----------------------------------
>
>This bugcheck seems to have nothing to do with my driver, but it
>obviously is related to the stop/start sequence it did.
>
>The most interesting thing is it always points to WRITE_ADDRESS: 08244c8b
>This address is reported every time in Windows 2003 SP1 x86 and
>Windows XP SP2 x86.
>
>
>So I suspect the method I currently use is not the right one.
>Maybe there is another method of doing the same that I could use?
>
>Thank you in advance for any help.
>
>Best regards,
>Valeriy Glushkov
>
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
Hi,
Of course the device is a prototype version that will be fixed in the next iterations.
But for the moment I have to work around the issue.
I’ll try to rewrite the config space manually. Thank you.
What is the recommended method of restoring the config space?
Best regards,
Valeriy Glushkov
----- Original Message -----
From: zeppelin@io.com
To: Windows System Software Devs Interest List
Sent: Sunday, October 15, 2006 2:47 AM
Subject: Re: [ntdev] Problems with restoring the config space of a buggy PCI device
Can you just keep a copy of your config space settings and rewrite it after detecting the reset? Seems like it might be easier. I hope they are going to fix that hardware before you ship. My pet peeve is hardware engineers tossing issues over the fence to the poor software guy.
-z
At 04:11 AM 10/14/2006, you wrote:
Hi All,
I have a buggy PCI board that disables its BAR registers on some internal conditions.
The device is used by my driver in PIO mode. It includes the config memory space, the data space and uses the interrupt.
That trace looks pretty familiar (I maintained the kernel audio stack up until about 18 months ago). I would check and see if your system manufacturer has an updated audio driver for your machine.
This may have happened because the rebalance affected the other PCI drivers as well (but that’s just a guess). The stack overall looks like a re-initialization. But I don’t believe you actually did anything wrong yourself.
Usually I see the last few stack entries when the vendor driver has “hijacked” the class driver dispatch table so it can support a non-audio device it has spawned. It then passes the wrong traffic (i.e., calls for the non-audio device) under some conditions to the class driver, causing it to crash. I verified that this problem has been reported previously to the vendor.
Hi,
I tried to restore the config space without stopping/restarting of the FDO
and it works well.
Thank you for your help!
Best regards,
Valeriy Glushkov
??: zeppelin@io.com
???: Windows System Software Devs Interest List
???: 15 ??? 2006 ?. 2:47
???: Re: [ntdev] Problems with restoring the config space of a buggy PCI
device
Can you just keep a copy of your config space settings and rewrite it after
detecting the reset? Seems like it might be easier. I hope they are going
to fix that hardware before you ship. My pet peeve is hardware engineers
tossing issues over the fence to the poor software guy.
-z
Hi Bob,
Thank you for the information.
I also feel that the audio stack is to blame for the crashes as on 2 other
test machines the driver works well.
But I’ve changed the logic to simple restoring the PCI config space on a
device reset and it works well now.
Best regards,
Valeriy Glushkov
??: “Bob Kjelgaard”
???: “Windows System Software Devs Interest List”
???: 16 ??? 2006 ?. 17:33
???: RE: [ntdev] Problems with restoring the config space of a buggy PCI
device
That trace looks pretty familiar (I maintained the kernel audio stack up
until about 18 months ago). I would check and see if your system
manufacturer has an updated audio driver for your machine.
This may have happened because the rebalance affected the other PCI drivers
as well (but that’s just a guess). The stack overall looks like a
re-initialization. But I don’t believe you actually did anything wrong
yourself.
Usually I see the last few stack entries when the vendor driver has
“hijacked” the class driver dispatch table so it can support a non-audio
device it has spawned. It then passes the wrong traffic (i.e., calls for
the non-audio device) under some conditions to the class driver, causing it
to crash. I verified that this problem has been reported previously to the
vendor.