Modifying the One-Card Network Card Miniport Driver Test
The One-Card Network Card Miniport Driver Test executes the tux –o –d ndt_1c command line on default execution. You can modify the test by further editing the command line. For information about how to edit the command line for a test, see Editing the Command Line for a Test. The following table shows the modifications you can make to the test.
To modify the One-Card Network Card Miniport Driver Test
| To | Add this command-line parameter |
|---|---|
| Log information when a test confirms that a packet has been sent or received. | |
| Disable unbinding of other protocol drivers from the test adapter before the test is run. | |
| Not skip test case 8, which is skipped by default.
Only ISA and PCI network cards support test case 8. |
|
| Instruct test case 7 to fail when no packets are canceled.
By default, test case 7 does not fail when no packets are canceled. |
|
For information about configuring the target device and development workstation to run the test, see Running the One-Card Network Card Miniport Driver Test.
The following table shows the test cases for the One-Card Network Card Miniport Driver Test.
| Test case | Description |
|---|---|
| 1: Open\Close | Tests the ability to open and close an adapter multiple times. A Miniport driver is shielded from the opening of an adapter by the Ndt.dll protocol driver. As a result, this test case tests the Ndt.dll protocol driver rather than the miniport driver. This test case opens and closes one instance of NdisOpen 16 times, and then opens and closes 128 concurrent instances of NdisOpen 16 times. This test fails if the miniport driver has a problem with multiple open instances of NdisOpen. |
| 2: Send | Tests the ability to send data both singularly and in bursts. The test case attempts to send data to the various address types supported by the media type of the current driver. This test case fails if a problem occurs with sending packets. |
| 3: Loopback send | Tests for the ability to receive loopback packets with a variety of address types on multiple filter settings. The test uses one open instance to send loopback packets and eight instances to receive the packets. Each of the eight instances receiving the packets has a different filter setting, which allows for all supported filter settings to be tested quickly. This test case also verifies that no open instance receives a packet that it should not be receiving. This test case fails if a problem occurs with a filter setting in a driver. |
| 4: Loopback stress | Creates packets with various buffer configurations in order to perform 10 instances of the stress test on the loopback packets. This test case fails if a memory leak is detected. |
| 5: Set multicast | Tests the ability of the Ethernet and Fiber Distributed Data Interface (FDDI) drivers to create multiple multicast addresses. The test does not verify that the card is able to receive on each of the different addresses. The test verifies only that multicast addresses can be set and deleted. |
| 6: Reset | Attempts to reset the network card multiple times while simultaneously sending large numbers of packets. The test also verifies that the card can reset itself in order to properly handle packets that are ready to send when interrupted by a reset. This test case fails if the operation that resets the network card is implemented incorrectly. |
| 7: Cancel send | Runs the performance command with a flag that causes the Ndt.dll protocol driver to cancel packets. The performance command queues 100 packets to send. In the next packet to send, the performance command sets the cancel identification, and then attempts to cancel the send operation. This test case fails if an improper cancellation of a packet occurs. |
| 8: Fault handling | Sets bits in the registry for the network card driver using a fault injection feature of NDIS. These bits cause NDIS to fail the NdisMAllocateMapRegisters, NdisMRegisterInterrupt, NdisMAllocateSharedMemory, NdisMMapIoSpace, NdisMRegisterIoPortRange, ReadNdisGetSetBusConfigSpace, WriteNdisGetSetBusConfigSpace, and NdisMInitializeScatterGatherDma functions. The driver should not load correctly unless it does not call a particular function. |
| 9: Object identifiers | Performs a series of NdisRequest function calls to the driver. Verifies that the driver supports the querying of all required object identifiers. |
| 10: 64 bit object identifiers | Tests the OID_GEN_XMIT_OK and OID_GEN_RCV_OK object identifiers to verify that all queries are handled properly. Each object identifier is queried three times. The object identifier is queried once with a null buffer, once with a 4-byte buffer and once with an 8-byte buffer. |
Remarks
This test library can have one or more optional command-line entries to change the behavior of the test. To specify one or more optional command-line entries to the test library, you must use the –c command-line option. This option forces Tux to pass the specified string into the test library.
See Also
One-Card Network Card Miniport Driver Test | Running the One-Card Network Card Miniport Driver Test
Last updated on Friday, October 08, 2004
© 1992-2003 Microsoft Corporation. All rights reserved.