Modifying the One-Card Network Card Miniport Driver Test (Windows CE 5.0)
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 the fault injection NDIS technology.
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. |
| 11: Suspend and then resume | Tests the behavior of the network card driver when the test suspends and then resumes the operating system (OS). If the run-time image does not support the IOCTL_HAL_ENABLE_WAKE IOCTL or does not wake in response to a SYSINTR_RTC_ALARM interrupt, this test case is skipped. This test case suspends and then resumes the OS 5 times and then attempts to send data over the network card driver to verify that the driver is functional. |
| 12: Stress suspend and then resume | Tests power management of the network card driver and stresses the network card driver under suspend and resume operations.
This test case has three threads. The main thread performs suspend and resume operations. The second thread sends data continuously over the network card driver. The third thread queries object identifiers (OIDs) continuously. If the network card driver supports power management, the main thread requests that Device Manager put the network card into a D4 state. After one second, the main thread requests that Device Manager restore the network card to a D0 state. If the network card driver does not support power management, the main thread performs a reset operation on the network card and then waits for a random interval of time. This test case assesses the ability of the network card driver to process send requests and OID requests while undergoing power transition. This test case performs 25 suspend and then resume operations. |
| 13: Reset on resume | Tests the ability of the network card driver to restore its original settings when a resume operation resets the network card driver. This test case first sets a packet filter, multicast list size, and look-ahead buffer size. This test case then adds multicast addresses to the multicast list. After a reset operation, this test case verifies that the network card driver preserves its original settings. |
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
Send Feedback on this topic to the authors