Skip to main content

 none
Problem at [DF - PCI Root Port Surprise Remove Test (PCI devices only) (Reliability)] Test RRS feed

  • Question

  • Hello all,

    I'm developing a BDA Driver for a USB device and trying to pass all the tests in HLK. From 57 tests, the driver already passes 54 without problem, has an erratic behavior at 2 and always fails in the [DF - PCI Root Port Surprise Remove Test (PCI devices only) (Reliability)] test. I'd like to clear some doubts to decide how to continue.

    1) From the test description, this test "surprise removes the test device's PCI root port". My first doubt is the following: since it removes the PCI root port, it actually removes other USB devices together with mine. Is this understanding correct? If it is, than the test would depend not only on my driver's behavior, but also on other drivers (from every device plugged in the USB hub connected in this PCI port), is this correct?

    2) In one of my PCs, the network connection is made through a USB Ethernet adapter. This adapter goes offline during the test (probably because of what I mentioned above) and the Server is not able to communicate anymore. Can this be a cause of error? Or should the test run without problems after the setup is made?

    3) In order to debug problems with this test, my procedure was to surprise remove my device and see if there were any problems there. Some problems were found and corrected, but now surprise removing the device doesn't give me any errors and the test is still failing. Is there another method to try and emulate this test in order to debug with more precision?

    This is my first driver development, so I'm sorry if I'm grossly misunderstanding something.

    Thanks in advance for any help.

    Tuesday, November 8, 2016 7:00 PM

All replies

  • Is there any solution for this...for failing of [DF - PCI Root Port Surprise Remove Test (PCI devices only) (Reliability)] Test
    Tuesday, November 13, 2018 9:50 AM
  • Hello,

    Answer for 1) Yes your understanding is correct and yes your driver is dependent on the other drivers on the stack as well. 

    Answer for 2) It could be the cause of the problem. Tring a different USB ethernet adapter from a different manufacture may help eliminate the problem. This is sort of pealing of the onion issue that could take some trial and error before the base configuration of the system is in a state that is conductive to testing. 

    Answer for 3) Review this documentation: https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/device-devfund-additional-documentation

    It provides information on how to triage the failure and other tools that could be used to test with to help eliminate other driver problems. 

    Hope this helps.

    Tuesday, November 13, 2018 8:15 PM