Re: NdisDevicePnPEventSurpriseRemoved Event On Vista
- From: "Calvin Guan" <hguan@xxxxxxxxxxxxxxxxxxx>
- Date: Sun, 3 Dec 2006 16:33:25 -0800
Is your device PCIe?
The most common cause I've seen is PCIe link re-train failure after SUT
transitioned from Sn to S0 where 5>=n>0. When that happened, PCI.sys
wouldn't see the function while re-enumerating the bus or attempting to
power up the function by writing D0 to your PMCSR.
The situation gets worse and more confusing if the link glitch occurred
between 2 enumerations -- the first instance would get "surprise removal"
and a "new instance" then re-enumerated in the order of ms.. you would think
the device has always been on the bus but that may not be the case from the
bus's perspective.
Numerous parties could be responsible to this kind of failure. A bus tracing
would tell exactly why the link was choking, although setting up a PCIe
trace for a laptop with soldered-on chip is pain in the neck.
If your are not the developer of the nic, contact your system vendor for
help. Otherwise, they will go after you.:)
5. The OS then issues a NdisDevicePnPEventSurpriseRemoved PNP event to the
driver. I have set a breakpoint in the driver at this point and confirmed
through !pci f f that the device is still present on the PCI bus. The PCI
configuration status and command registers look fine.
That only means your device is still responding config cycles at the time
you tried to inspect it. It doesn't tell what had happened in the past.
--
Calvin Guan (DDK MVP)
Sr. Staff Engineer
NetXtreme Vista/LH Server Miniport
Broadcom Corporation
Connecting Everything(r)
"John Q. Public" <ImInSoquel@xxxxxxxxxxxxx> wrote in message
news:eA3TtUmFHHA.2468@xxxxxxxxxxxxxxxxxxxxxxx
Besides the obvious (removing the NIC), what conditions would cause the OS
to issue a PNP event of NdisDevicePnPEventSurpriseRemoved to an NDIS
miniport driver? On Vista build 6000, we are occasionally seeing this
event sent to the miniport following a resume from standby or hibernate.
When this happens, we are seeing the following:
1. The OS sets OID_PNP_SET_POWER to the miniport. So, the device is still
present on the PCI bus at this point. The driver completes the set request
with NDIS_STATUS_SUCCESS.
2. The OS issues a NdisDevicePnPEventPowerProfileChanged PNP event to the
driver.
3.The OS restarts the miniport and rebinds the protocol stacks to the
miniport.
4. Various OID set and query requests are made, each of which are
completed with NDIS_STATUS_SUCCESS by the driver.
5. The OS then issues a NdisDevicePnPEventSurpriseRemoved PNP event to the
driver. I have set a breakpoint in the driver at this point and confirmed
through !pci f f that the device is still present on the PCI bus. The PCI
configuration status and command registers look fine.
We are seeing this behaior on different types of laptops, such as the HP
Pavillion. On one such laptop, I upgraded the BIOS to be the most recent
available.
Any help would be greatly appreciated.
Thanks!
.
- References:
- NdisDevicePnPEventSurpriseRemoved Event On Vista
- From: John Q. Public
- NdisDevicePnPEventSurpriseRemoved Event On Vista
- Prev by Date: Re: device class of tdi filter and tdi client
- Next by Date: kernel mode n/w programming
- Previous by thread: NdisDevicePnPEventSurpriseRemoved Event On Vista
- Next by thread: Re: kmdf port
- Index(es):
Relevant Pages
|