Registry changes for PCI bus filter driver

NTDEV
1

I’ve been working through several examples of source code that have taught me a lot about upper and lower filter drivers, however now I’m wanting to make a bus filter driver and there’s a lot less documentation in this area than the standard upper/lower ones. Filter drivers are easily added by [basically] creating a service and modifying the desired key’s UpperFilters/LowerFilters value to that service name, however what registry entries should a PCI bus filter driver modify? The “PCI Bus” entry under the “HKLM\SYSTEM\CurrentControlSet\Control\Class{ … System GUID … }”?

Any clarification in this area would be greatly appreciated – code/examples from INF’s would be even more gooder :slight_smile:

-Thomas

2

The last time I did this for a client (quite a while ago) I used

HKLM,
System\CurrentControlSet\Control\Class{4d36e97d-e325-11ce-bfc1-08002be10318
}, UpperFilters, 0x00010008,XXX

Where XXX was my service. Be aware a PCI Bus filter will have a lot of
special handling to get it to work.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@magma.com
Sent: Friday, July 05, 2013 5:38 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Registry changes for PCI bus filter driver

I’ve been working through several examples of source code that have taught
me a lot about upper and lower filter drivers, however now I’m wanting to
make a bus filter driver and there’s a lot less documentation in this area
than the standard upper/lower ones. Filter drivers are easily added by
[basically] creating a service and modifying the desired key’s
UpperFilters/LowerFilters value to that service name, however what registry
entries should a PCI bus filter driver modify? The “PCI Bus” entry under the
“HKLM\SYSTEM\CurrentControlSet\Control\Class{ … System GUID … }”?

Any clarification in this area would be greatly appreciated – code/examples
from INF’s would be even more gooder :slight_smile:

-Thomas

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

3

Don,

This would make your service XXX an upper filter driver for ALL system devices then, if I’m not mistaken?

-----Original Message-----
The last time I did this for a client (quite a while ago) I used

HKLM,
System\CurrentControlSet\Control\Class{4d36e97d-e325-11ce-bfc1-08002be10318
}, UpperFilters, 0x00010008,XXX

Where XXX was my service. Be aware a PCI Bus filter will have a lot of
special handling to get it to work.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

4

Don,

Also, (sorry for double-posting), as Doron Holon posted here:
[http://www.osronline.com/showThread.CFM?link=180028]

“While most of that would actually fool KMDF in to doing the right thing, there are special bus filter rules in handling pnp state changes that KMDF would not follow if it were in a bus filter role. There is no way to fool KMDF’s pnp WDFDEVICE to do the right thing here.”

My ultimate goal includes being able to receive PnP state changes with this bus filter driver – something not supported by KMDF drivers? Also, what does Doron mean by “in a bus filter role”. Is instantiating a bus filter driver as easy as just inserting a regular KMDF filter driver’s service name into the correct key in the registry? From your previous post this sounds [partially] true?

Thanks Don,

-Thomas

5

Sorry, had to go back and check the code, what I did at that point was use
IoGetDeviceProperty in AddDevice to get the hardware ID then compare it to:
“ACPI\PNP0A08” and “ACPI\PNP0A03”

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@magma.com
Sent: Friday, July 05, 2013 6:10 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Registry changes for PCI bus filter driver

Don,

This would make your service XXX an upper filter driver for ALL system
devices then, if I’m not mistaken?

-----Original Message-----
The last time I did this for a client (quite a while ago) I used

HKLM,
System\CurrentControlSet\Control\Class{4d36e97d-e325-11ce-bfc1-08002be10318
}, UpperFilters, 0x00010008,XXX

Where XXX was my service. Be aware a PCI Bus filter will have a lot of
special handling to get it to work.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

6

What bigger problem are you solving? Kmdf can’t be used as a bus filter role in any way

d

Bent from my Phone

From: xxxxx@magma.commailto:xxxxx
Sent: ?7/?5/?2013 6:26 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Registry changes for PCI bus filter driver

Don,

Also, (sorry for double-posting), as Doron Holon posted here:
[http://www.osronline.com/showThread.CFM?link=180028]

“While most of that would actually fool KMDF in to doing the right thing, there are special bus filter rules in handling pnp state changes that KMDF would not follow if it were in a bus filter role. There is no way to fool KMDF’s pnp WDFDEVICE to do the right thing here.”

My ultimate goal includes being able to receive PnP state changes with this bus filter driver – something not supported by KMDF drivers? Also, what does Doron mean by “in a bus filter role”. Is instantiating a bus filter driver as easy as just inserting a regular KMDF filter driver’s service name into the correct key in the registry? From your previous post this sounds [partially] true?

Thanks Don,

-Thomas

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

7

Basically you have to do a WDM driver for a bus filter. One of the
challenges of a bus filter is you won’t see the AddDevice for the children
of the bus, but these can for PCI example include a bridge which means
another PCI bus. So unless you create your own state machine and have the
“real AddDevice” and the “internal AddDevice” you are not going get
everything you need. Bottom line I had done a bunch of WDM filter drivers
before I ever tried the bus filter, and it felt like I was doing almost
everything for the first time.

There are reasons for bus filter drivers, but be sure you have one.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@magma.com
Sent: Friday, July 05, 2013 6:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Registry changes for PCI bus filter driver

Don,

Also, (sorry for double-posting), as Doron Holon posted here:
[http://www.osronline.com/showThread.CFM?link=180028]

“While most of that would actually fool KMDF in to doing the right thing,
there are special bus filter rules in handling pnp state changes that KMDF
would not follow if it were in a bus filter role. There is no way to fool
KMDF’s pnp WDFDEVICE to do the right thing here.”

My ultimate goal includes being able to receive PnP state changes with this
bus filter driver – something not supported by KMDF drivers? Also, what
does Doron mean by “in a bus filter role”. Is instantiating a bus filter
driver as easy as just inserting a regular KMDF filter driver’s service name
into the correct key in the registry? From your previous post this sounds
[partially] true?

Thanks Don,

-Thomas

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

8

Thanks for clarifying that Doron, I wasn’t sure.

My first goal is to develop a simple passive bus filter driver that can exist on it’s own by just passing data along and not really doing anything and receive PnP events. Specifically, PCI-Express PnP (removal) events to handle the removal of devices from the PCI-Express tree *before* the functional driver is informed of the PnP event. It’s my understanding that bus drivers are informed of such PnP events before the device drivers are?

I also hope to be able to read/write to the config space of each PCI-Express card in the system, but that’s goal number two, which was part of the reason why I was hoping to fit goal #1 into a bus filter driver as to keep it to one driver rather than two separate ones.

-Thomas

------Original message------
What bigger problem are you solving? Kmdf can’t be used as a bus filter role in
any way

d

Bent from my Phone

9

On physical removal, you will see the removal of the device in the qdr/devicerelations, but that is the only time you would see it ahead of the functional stack. Otherwise you see it at the same time. I don’t really see the value in cresting a bus filter just for that

d

Bent from my Phone

From: xxxxx@magma.commailto:xxxxx
Sent: ?7/?5/?2013 7:08 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Registry changes for PCI bus filter driver

Thanks for clarifying that Doron, I wasn’t sure.

My first goal is to develop a simple passive bus filter driver that can exist on it’s own by just passing data along and not really doing anything and receive PnP events. Specifically, PCI-Express PnP (removal) events to handle the removal of devices from the PCI-Express tree before the functional driver is informed of the PnP event. It’s my understanding that bus drivers are informed of such PnP events before the device drivers are?

I also hope to be able to read/write to the config space of each PCI-Express card in the system, but that’s goal number two, which was part of the reason why I was hoping to fit goal #1 into a bus filter driver as to keep it to one driver rather than two separate ones.

-Thomas

------Original message------
What bigger problem are you solving? Kmdf can’t be used as a bus filter role in
any way

d

Bent from my Phone

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

10

Doron,

My ultimate goal is to gracefully handle the removal of various PCI-Express cards running in PCI-Express expansion bay(s) via a Thunderbolt connection. These can be unplugged at any time and usually immediately causes a BSOD (obviously, you just unplugged a graphics card or something). I hope to receive these PnP events to disable the entire Lightridge/Eagleridge/etc (Intel’s Thunderbolt PCI-E bridge chips) part of the PCI-E tree and investigate if there is a graceful solution to this.

Obviously the cards would no longer work, however accessing those resources shouldn’t be allowed since they are no longer physically present. In fact, when no Thunderbolt connection is currently made to any of Intel’s Thunderbolt chips, it would appear as if the bus driver (pci.sys) simply deletes them from the entire PCI-E tree. Not sure if this is done before or after the upper part of the stack sees a PnP removal event, but this is all part of my R&D at the moment and hope to find out.

-Thomas Gray

------Original Message------
On physical removal, you will see the removal of the device in the
qdr/devicerelations, but that is the only time you would see it ahead of the
functional stack. Otherwise you see it at the same time. I don’t really see the
value in cresting a bus filter just for that

d

Bent from my Phone

11

BSOD on unplug is caused by things outside of your control.

If a driver cannot handle the registers suddenly reading all FFFFFFF, and bombs, or spins while waiting for a bit to change to zero, you cannot fix that. You need to fix the driver (which could be third-party)

If a BSOD is caused by the momentary bus error during the unplug and causes WHEA bugcheck, you cannot fix that.

When the drivers see IRP_MJ_SURPRISE_REMOVAL, the access to registers is already impossible. The drivers should be designed to be able to handle that.

Once again, no filter can fix that.

12

I think your time would be better spent root causing the bsod reason vs a bus filter. The bus filter can’t prevent the driver from going off the deep end. Perhaps if the bsos is caused by PCI.sys itself you have an extremely outside chance of working around the issue

d

Bent from my Phone

From: xxxxx@magma.commailto:xxxxx
Sent: ?7/?5/?2013 7:58 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Registry changes for PCI bus filter driver

Doron,

My ultimate goal is to gracefully handle the removal of various PCI-Express cards running in PCI-Express expansion bay(s) via a Thunderbolt connection. These can be unplugged at any time and usually immediately causes a BSOD (obviously, you just unplugged a graphics card or something). I hope to receive these PnP events to disable the entire Lightridge/Eagleridge/etc (Intel’s Thunderbolt PCI-E bridge chips) part of the PCI-E tree and investigate if there is a graceful solution to this.

Obviously the cards would no longer work, however accessing those resources shouldn’t be allowed since they are no longer physically present. In fact, when no Thunderbolt connection is currently made to any of Intel’s Thunderbolt chips, it would appear as if the bus driver (pci.sys) simply deletes them from the entire PCI-E tree. Not sure if this is done before or after the upper part of the stack sees a PnP removal event, but this is all part of my R&D at the moment and hope to find out.

-Thomas Gray

------Original Message------
On physical removal, you will see the removal of the device in the
qdr/devicerelations, but that is the only time you would see it ahead of the
functional stack. Otherwise you see it at the same time. I don’t really see the
value in cresting a bus filter just for that

d

Bent from my Phone

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

13

+1 to what was said below.

PCI(e) drivers need to assure they don’t do anything stupid if they suddenly read all 0xFFs.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Friday, July 05, 2013 5:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Registry changes for PCI bus filter driver

BSOD on unplug is caused by things outside of your control.

If a driver cannot handle the registers suddenly reading all FFFFFFF, and bombs, or spins while waiting for a bit to change to zero, you cannot fix that. You need to fix the driver (which could be third-party)

If a BSOD is caused by the momentary bus error during the unplug and causes WHEA bugcheck, you cannot fix that.

When the drivers see IRP_MJ_SURPRISE_REMOVAL, the access to registers is already impossible. The drivers should be designed to be able to handle that.

Once again, no filter can fix that.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

14

Well, defensive programming against this can help some. But the driver can
read all-one at anytime if the hw can be yanked at anytime. Even the driver
check all-one for every reg read (would be interested to see such driver),
there are occasions that system crashes before your driver can react.

Handling SR on PCI bus is always best effort in my book.

On Fri, Jul 5, 2013 at 8:20 PM, Jan Bottorff wrote:

> +1 to what was said below.
>
> PCI(e) drivers need to assure they don’t do anything stupid if they
> suddenly read all 0xFFs.
>
> Jan
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
> Sent: Friday, July 05, 2013 5:35 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] Registry changes for PCI bus filter driver
>
> BSOD on unplug is caused by things outside of your control.
>
> If a driver cannot handle the registers suddenly reading all FFFFFFF, and
> bombs, or spins while waiting for a bit to change to zero, you cannot fix
> that. You need to fix the driver (which could be third-party)
>
> If a BSOD is caused by the momentary bus error during the unplug and
> causes WHEA bugcheck, you cannot fix that.
>
> When the drivers see IRP_MJ_SURPRISE_REMOVAL, the access to registers is
> already impossible. The drivers should be designed to be able to handle
> that.
>
> Once again, no filter can fix that.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

15

Back when I was working for Stratus we developed a full set of standard pci
drivers (disk/net/video) that had to do just that: survive any random
unplug event, as we supported hot plug redundant IO controllers that could
essentially disconnect (or connect) an entire top level PCI Bus and all of
its component PCI devices. It was indeed a major undertaking, but it is
actually not as difficult as it might seem, more tedious than difficult.

Back to the OP’s issue - he can’t mask or defer or ‘soften’ the unplug,
that is not going to happen on a bus that gives independent components
access to the bus address space, so there really is no point in a bus
filter driver.

Mark Roddy

On Sun, Jul 7, 2013 at 3:22 PM, Calvin Guan (news) > wrote:

> Well, defensive programming against this can help some. But the driver can
> read all-one at anytime if the hw can be yanked at anytime. Even the driver
> check all-one for every reg read (would be interested to see such driver),
> there are occasions that system crashes before your driver can react.
>
> Handling SR on PCI bus is always best effort in my book.
>
>
> On Fri, Jul 5, 2013 at 8:20 PM, Jan Bottorff wrote:
>
>> +1 to what was said below.
>>
>> PCI(e) drivers need to assure they don’t do anything stupid if they
>> suddenly read all 0xFFs.
>>
>> Jan
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:
>> xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
>> Sent: Friday, July 05, 2013 5:35 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE:[ntdev] Registry changes for PCI bus filter driver
>>
>> BSOD on unplug is caused by things outside of your control.
>>
>> If a driver cannot handle the registers suddenly reading all FFFFFFF, and
>> bombs, or spins while waiting for a bit to change to zero, you cannot fix
>> that. You need to fix the driver (which could be third-party)
>>
>> If a BSOD is caused by the momentary bus error during the unplug and
>> causes WHEA bugcheck, you cannot fix that.
>>
>> When the drivers see IRP_MJ_SURPRISE_REMOVAL, the access to registers is
>> already impossible. The drivers should be designed to be able to handle
>> that.
>>
>> Once again, no filter can fix that.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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 Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers 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
>

16

Define “any random unplug event”. Consider scenario like this:
A pci device is physically removed while it’s in the middle of a bus
cycle. By PCI protocol, you will get a initiator abort or target abort. On
many systems, target abort is wired to SERR which results in NMI.

Have you proved or observed electrically that your device and driver
actually survived?

On Sun, Jul 7, 2013 at 2:00 PM, Mark Roddy wrote:

> Back when I was working for Stratus we developed a full set of standard
> pci drivers (disk/net/video) that had to do just that: survive any random
> unplug event, as we supported hot plug redundant IO controllers that could
> essentially disconnect (or connect) an entire top level PCI Bus and all of
> its component PCI devices. It was indeed a major undertaking, but it is
> actually not as difficult as it might seem, more tedious than difficult.
>
> Back to the OP’s issue - he can’t mask or defer or ‘soften’ the unplug,
> that is not going to happen on a bus that gives independent components
> access to the bus address space, so there really is no point in a bus
> filter driver.
>
> Mark Roddy
>
>
> On Sun, Jul 7, 2013 at 3:22 PM, Calvin Guan (news) <
> xxxxx@gradovec.com> wrote:
>
>> Well, defensive programming against this can help some. But the driver
>> can read all-one at anytime if the hw can be yanked at anytime. Even the
>> driver check all-one for every reg read (would be interested to see such
>> driver), there are occasions that system crashes before your driver can
>> react.
>>
>> Handling SR on PCI bus is always best effort in my book.
>>
>>
>> On Fri, Jul 5, 2013 at 8:20 PM, Jan Bottorff wrote:
>>
>>> +1 to what was said below.
>>>
>>> PCI(e) drivers need to assure they don’t do anything stupid if they
>>> suddenly read all 0xFFs.
>>>
>>> Jan
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com [mailto:
>>> xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
>>> Sent: Friday, July 05, 2013 5:35 PM
>>> To: Windows System Software Devs Interest List
>>> Subject: RE:[ntdev] Registry changes for PCI bus filter driver
>>>
>>> BSOD on unplug is caused by things outside of your control.
>>>
>>> If a driver cannot handle the registers suddenly reading all FFFFFFF,
>>> and bombs, or spins while waiting for a bit to change to zero, you cannot
>>> fix that. You need to fix the driver (which could be third-party)
>>>
>>> If a BSOD is caused by the momentary bus error during the unplug and
>>> causes WHEA bugcheck, you cannot fix that.
>>>
>>> When the drivers see IRP_MJ_SURPRISE_REMOVAL, the access to registers is
>>> already impossible. The drivers should be designed to be able to handle
>>> that.
>>>
>>> Once again, no filter can fix that.
>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> 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
>>>
>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> 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 Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers 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 Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers 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
>

17

I once worked on h/w that handled such occurrences. PCI cards were carried
in caddies that could be pulled out at any time. FETs made sure the card
was electrically isolated unless it was actively involved in a cycle and a
custom PCI-PCI bridge squashed any fallout from device removal during a
cycle.

Paul

On 8 July 2013 07:41, Calvin Guan (news) wrote:

> Define “any random unplug event”. Consider scenario like this:
> A pci device is physically removed while it’s in the middle of a bus
> cycle. By PCI protocol, you will get a initiator abort or target abort.
> On many systems, target abort is wired to SERR which results in NMI.
>
> Have you proved or observed electrically that your device and driver
> actually survived?
>
>
> On Sun, Jul 7, 2013 at 2:00 PM, Mark Roddy wrote:
>
>> Back when I was working for Stratus we developed a full set of standard
>> pci drivers (disk/net/video) that had to do just that: survive any random
>> unplug event, as we supported hot plug redundant IO controllers that could
>> essentially disconnect (or connect) an entire top level PCI Bus and all of
>> its component PCI devices. It was indeed a major undertaking, but it is
>> actually not as difficult as it might seem, more tedious than difficult.
>>
>> Back to the OP’s issue - he can’t mask or defer or ‘soften’ the unplug,
>> that is not going to happen on a bus that gives independent components
>> access to the bus address space, so there really is no point in a bus
>> filter driver.
>>
>> Mark Roddy
>>
>>
>> On Sun, Jul 7, 2013 at 3:22 PM, Calvin Guan (news) <
>> xxxxx@gradovec.com> wrote:
>>
>>> Well, defensive programming against this can help some. But the driver
>>> can read all-one at anytime if the hw can be yanked at anytime. Even the
>>> driver check all-one for every reg read (would be interested to see such
>>> driver), there are occasions that system crashes before your driver can
>>> react.
>>>
>>> Handling SR on PCI bus is always best effort in my book.
>>>
>>>
>>> On Fri, Jul 5, 2013 at 8:20 PM, Jan Bottorff wrote:
>>>
>>>> +1 to what was said below.
>>>>
>>>> PCI(e) drivers need to assure they don’t do anything stupid if they
>>>> suddenly read all 0xFFs.
>>>>
>>>> Jan
>>>>
>>>> -----Original Message-----
>>>> From: xxxxx@lists.osr.com [mailto:
>>>> xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
>>>> Sent: Friday, July 05, 2013 5:35 PM
>>>> To: Windows System Software Devs Interest List
>>>> Subject: RE:[ntdev] Registry changes for PCI bus filter driver
>>>>
>>>> BSOD on unplug is caused by things outside of your control.
>>>>
>>>> If a driver cannot handle the registers suddenly reading all FFFFFFF,
>>>> and bombs, or spins while waiting for a bit to change to zero, you cannot
>>>> fix that. You need to fix the driver (which could be third-party)
>>>>
>>>> If a BSOD is caused by the momentary bus error during the unplug and
>>>> causes WHEA bugcheck, you cannot fix that.
>>>>
>>>> When the drivers see IRP_MJ_SURPRISE_REMOVAL, the access to registers
>>>> is already impossible. The drivers should be designed to be able to handle
>>>> that.
>>>>
>>>> Once again, no filter can fix that.
>>>>
>>>>
>>>> —
>>>> NTDEV is sponsored by OSR
>>>>
>>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>>
>>>> OSR is HIRING!! See http://www.osr.com/careers
>>>>
>>>> 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
>>>>
>>>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>>>
>>>> OSR is HIRING!! See http://www.osr.com/careers
>>>>
>>>> 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 Visit the list at:
>>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>>> http://www.osr.com/careers 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 Visit the list at:
>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>> http://www.osr.com/careers 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 Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers 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
>

–
Paul Durrant
http://www.linkedin.com/in/pdurrant

18

> ------------------------------------------------------------------------

Don Burn:

Basically you have to do a WDM driver for a bus filter. One of the
challenges of a bus filter is you won’t see the AddDevice for the children
of the bus, but these can for PCI example include a bridge which means
another PCI bus. So unless you create your own state machine and have the
“real AddDevice” and the “internal AddDevice” you are not going get
everything you need. Bottom line I had done a bunch of WDM filter drivers
before I ever tried the bus filter, and it felt like I was doing almost
everything for the first time.

Don, I currently have the source code for a previous [working, WDM] PCI bus filter driver made by a software engineer at the company I work for, however only the source code was preserved and I have no idea of how to actually insert the driver into registry. Only the source files, themselves, were preserved with no remnants of any instructions on how to actually insert the driver into the system or any such INF. It would be nice to get this working again, however I just have no idea how to insert a WDM filter driver into the registry, and your previous recommendation sounds like it’s for KMDF upper/lower filter drivers and would end up throwing the driver into a different part of the driver stack than what this was meant to function under.

Also, yes – the source code for this driver is very extensive and looks like it was a lot of work. Glad I have something to work off of rather than having to design this from scratch.

Here is a link to a [somewhat relevant] post made by the software engineer who previously wrote this driver:
http://www.osronline.com/showThread.cfm?link=83377

I have played around with different methods of doing what you’ve said previously (by attaching to the PCI bus and filtering for “ACPI\PNP0A0(8/3)”. Would registering my driver to attach to “*PNP0A08” and “*PNP0A03” devices in my INF file have the same affect? I guess the only difference would be that you could filter out different devices on the fly with your method if you didn’t want to specifically attach to only PCI devices? Either way, this method seems as though it’s still attaching above/below the device driver and not a part of the bus driver, itself.

Mark Roddy:

Back to the OP’s issue - he can’t mask or defer or ‘soften’ the unplug,
that is not going to happen on a bus that gives independent components
access to the bus address space, so there really is no point in a bus
filter driver.

I agree this should be something handled within the driver of the device, itself, however we have no control over what hardware people put into our PCI-Express expansion systems so a “device-independent solution” was discussed and words like a “bus filter driver” were being thrown around to possibly handle unplug events for all devices behind our PCI-Express switches. Sounded like my best shot so I continued doing research in the area but it sounds like this path won’t come to frution if all the previous posts are true.

So to confirm with the NTDEV community, it would seem that the ONLY way to gracefully handle surprise removals is in the driver of the device, itself, and no amount of bus filter drivers can help alleviate [or help gracefully handle] this problem?

Also, any resources related to inserting *WDM* pci bus filter drivers would be much appreciated, I still can’t seem to find anything online but my search continues…

-Thomas Gray