IOCTL_PROCESSOR_INFORMATION Test (Compact 2013)
3/26/2014
The IOCTL_PROCESSOR_INFORMATION Test verifies the correct implementation of IOCTL_PROCESSOR_INFORMATION.
Test Prerequisites
Your device must meet the following requirements before you run this test.
As with the other OEM adaptation layer (OAL) IOCTL tests, the IOCTL_PROCESSOR_INFORMATION test requires no additional hardware.
- You must run the test on a minimal OS design, such as the "BTS Minimal OAL" image.
- The image must implement IOCTL_PROCESSOR_INFORMATION.
The following table describes the software requirements for the test:
Requirements |
Description |
---|---|
Tux.exe |
Tux test harness, required to execute the test |
kato.dll |
Kato logging engine, required for logging the test data |
oaltestioctls.dll |
Library that contains OAL IOCTL Test files |
Subtests
The following table lists the subtests included in this test.
SubTest ID |
Description |
---|---|
5100 |
Prints out the usage message for the IOCTL_PROCESSOR_INFORMATION tests. |
5101 |
Prints the output of IOCTL_PROCESSOR_INFORMATION. Verify the output manually. |
5102 |
Checks IOCTL_PROCESSOR_INFORMATION by using incorrect inbound parameters. |
5103 |
Checks IOCTL_PROCESSOR_INFORMATION by using incorrect outbound parameters. |
5104 |
Checks IOCTL_PROCESSOR_INFORMATION by using different alignments of the output buffer, and also output buffer overflow. |
Setting Up the Test
This test has no additional requirements beyond the standard test environment setup.
Running the Test
The default test command line is as follows:
tux.exe -o -d oalTestIoctls.dll -x5100-5104
Verifying the Test
- When the test finishes running, verify that 'PASS' appears in the test log for all subtests.
- Manually verify the printed output from test case 5101.
Troubleshooting the Test
- Review the implementation of IOCTL_PROCESSOR_INFORMATION in the OAL. The microprocessor core, name, vendor, instruction set, clock speed and other fields must be set correctly or detected in the implementation.
- Determine the point of failure and record the exact error message. If the source code is available, examine the point of failure in the code to see whether you can collect any additional information about the failure domain.