I have a strange situation where the presence of our custom KMDF PCI card driver seems to interfere with the operation of a bridged network card configuration.
Someone here has tried changing the startup type of our driver from DEMAND_START to BOOT_START (which I know is not correct practice), and this seems to avoid the problem.
Has anyone out there in the driver community experienced anything similar?
Also, please note that our custom PCI card has nothing to do with networking.
ntdev member 11288 wrote:
Also, please note that our custom PCI card has nothing
to do with networking.
What *does* it have to do with?
PCI card (with an embedded 68000 processor and associated firmware) provides connectivity from our older laboratory instruments (via IEEE-488) to our data system (running on the PC).
The KMDF driver employs a Common Buffer DMA design utilizing an array of dual intermediate common buffers (one for read, one for write) in a PCI bus mastering scheme, along with interrupt signalling and PIO control registers.
>I have a strange situation where the presence of our custom KMDF PCI card driver seems to interfere >with the operation of a bridged network card configuration.
Could you be more specific on this statement? How does your card interfere a network card?
The only interference could be if the driver of your card overwrites memory which not belongs to the driver. Did you test your driver by using Driver Verifier? If you didn’t, try to use it. It may help you.
Igor Sharovar
The problem only occurs in the bridged configuration, where bridge.sys is used. (I assume this is either an NDIS intermediate driver or an NDIS filter driver.) There are 3 PCI Express network cards involved. If we do not configure a bridged network, but rather just use any of the cards directly, it works fine.
The bridged LAN presents as non-operational. Attempts to “repair” the network by enabling / disabling / diagnosing are unsuccessful. No packets sent or received.
While I don’t yet understand the root cause of the problem, the curious observation is that changing the Start Type of our PCI card driver to BOOT_START (which I know is not proper for a PNP driver) seems to avoid the problem. Any speculation on why?
Yes, we have used Driver Verifier and no errors are reported.
Could it be specific to that mother board and or even slot? Have you moved
PCI boards around to see if things change?
Given you have eleminated the obvious hardware oopsies, it could very well
be that you have a chained interrupt problem and a driver upstream in the
chain is not treating the interrupt nicely before it “releases” things. You
might check to see who else is on the same interrupt with you, and then
Enable/Disable them in Device Manager until you find the culprit.
Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@waters.com
Sent: Tuesday, April 06, 2010 11:20 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Vista and Win7 MAC Bridge Miniport interference from PCI
card driver
The problem only occurs in the bridged configuration, where bridge.sys is
used. (I assume this is either an NDIS intermediate driver or an NDIS
filter driver.) There are 3 PCI Express network cards involved. If we do
not configure a bridged network, but rather just use any of the cards
directly, it works fine.
The bridged LAN presents as non-operational. Attempts to “repair” the
network by enabling / disabling / diagnosing are unsuccessful. No packets
sent or received.
While I don’t yet understand the root cause of the problem, the curious
observation is that changing the Start Type of our PCI card driver to
BOOT_START (which I know is not proper for a PNP driver) seems to avoid the
problem. Any speculation on why?
Yes, we have used Driver Verifier and no errors are reported.
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
__________ Information from ESET Smart Security, version of virus signature
database 5004 (20100406) __________
The message was checked by ESET Smart Security.
__________ Information from ESET Smart Security, version of virus signature
database 5004 (20100406) __________
The message was checked by ESET Smart Security.
In additional to Gary advises I would recommend to use a PCI bus analyzer. You may see some error PCI transactions which would help to identify the problem.
You could also enable NDIS tracing in WinDbg to see if there is any problem in the bridge.
Igor Sharovar
Some further information:
– Motherboard on this system has 1 PCI slot, 1 PCI Express x16 slot, 2 PCI Express x1 slots
– Our card is PCI, so cannot try it in another slot
– Network cards as follows:
. PCI Express x16 slot –> Intel PRO/1000 PT Dual Port Server Adapter
. PCI Express x1 slot –> Intel Gigabit CT Desktop Adapater
. PCI Express x1 slot –> Intel Gigabit CT Desktop Adapater
Checked IRQ assignments under Case A (our PCI driver as DEMAND_START) vs. Case B (our PCI driver as BOOT_START). To reiterate, Case A fails, Case B works. All IRQ assignments remain the same, as follows:
– Our PCI card –> IRQ 21
– USB Host Controller –> IRQ 21
– 1st port of Intel PRO/1000 PT card –> IRQ -7 (MSI)
– 2nd port of Intel PRO/1000 PT card –> IRQ -6 (MSI)
– 1st Intel Gigabit CT card –> IRQ -33 to -22 (MSI)
– 2nd Intel Gigabit CT card –> IRQ -21 to -10 (MSI)
Try to enable NDIS tracing for the Case A that I suggested early. This may show additional information.
Igor Sharovar