Test Cases for the Interrupt IOCTLs Test (User Mode) (Windows Embedded CE 6.0)
1/6/2010
The following table shows the test cases for the Interrupt IOCTLs Test (User Mode). Note the following points:
- The allocation and release tests can run on any image. These tests must be signed so that they have low level access to the interrupt IOCTL routines.
- IRQ ranges are used throughout the code. The default ranges are currently set from 0 to 1024. For some of the tests, the IRQ range can be set by the command line arguments. All IRQ ranges are inclusive, unless specified otherwise.
- The IOCTLs should only be called in kernel mode. In user mode, the kernel should prevent the OAL code from even being called. The test is run in user mode to confirm that none of the calls complete successfully.
- The IOCTL test code has numerous internal checks that confirm that the correct data is returned. Two important ones:
- Valid SYSINTRs: Valid SYSINTRs must be between [0, 71]. Anything else is an error.
- Number of free SYSINTRs before and after the test: The tests are designed to leave the system in the state that they found it in. This can be confirmed by comparing the number of free SYSINTRs before and after the test. This helps catch errors both on the tests and errors in the routines themselves.
- Given the demands of different customers and the constraints imposed by kernel vs. user mode, the Tux function table enumerates all of the possible combinations needed to fully test the IOCTLs. Since some of the init routines require kernel mode access, these cannot be run from user mode. Therefore, allowing every function table entry to be run from user mode would subject the user to confusing messages. Furthermore, this would be difficult to code and maintain, since some functions call init routines many levels deep. By denoting certain test cases as "user mode" and others as "kernel mode", the user can pick and choose based from how the tests are run.
- "Extended flag structure" allows the OAL_INTR_* flags to specify more actions to the IOCTLs.
- Since the interrupt routines control essential system behavior, trashed tables that map the IRQs to SYSINTRs generally lead to system instability and crashes. This means that the pedantic user would run each test case individually. Instead, these tests run in two passes in CETK: kernel mode and user mode (these require different command lines). A failure in the test will normally break all of the others. This needs be noted for anyone looking at CETK results.
| Test case | Description |
|---|---|
500 |
IOCTL_HAL_REQUEST_SYSINTR: Bad Input (Extended flag structure) - Incomplete Args IRQ Range: Command line or default Checks the following:
|
510 |
IOCTL_HAL_REQUEST_SYSINTR: Bad Input (Extended flag structure) - Bad Input Sizes IRQ Range: Command or default Inbound structure must be DWORDs, so length much always be a multiple of four. Furthemore, it must always be > 2 DWORDs, or 8 bytes. Confirm this up to an arbitrary 32 bytes. |
520 |
IOCTL_HAL_REQUEST_SYSINTR: Bad Input-Size IRQ Range: Command line or default Confirm that anything except for 4 bytes causes a failure. |
530 |
IOCTL_HAL_REQUEST_SYSINTR: Bad Flags IRQ Range: Command line or default Test works from 0 to 256, skipping the valid flags (OAL_INTR_TRANSLATE, OAL_INTR_STATIC, OAL_INTR_DYNAMIC, OAL_INTR_FORCE_STATIC). |
540 550 |
Test case 540: IOCTL_HAL_REQUEST_SYSINTR: Bad Out-Size (Extended flag structure) Test case 550: IOCTL_HAL_REQUEST_SYSINTR: Bad Out-Size IRQ Range: Command line or default Any size less than 4 bytes causes failure. Note that only 4 bytes is needed for output. If given more, the IOCTL just ignores it. |
600 |
IOCTL_HAL_RELEASE_SYSINTR: Bad Input Size IRQ Range: Command line or default Confirm that anything other than 4 bytes causes an error. This IOCTL passes no output. In this case the code is supposed to completely ignore the output values, include lpBytesReturned. |
1000 |
Free SYSINTRs that should not be freed Any SYSINTR less than 8 or greater than 71 is not valid. Freeing these should result in FALSE from the IOCTL and no change in the system. This test tries to release these SYSINTRs. Since releasing ~ 2^32 interrupts takes a long time, we hit the most likely values:
|
12000 12100 12200 |
Test case 12000: Single IRQ Allocations: Single IRQ Standard Alloc Test case 12100: Single IRQ Allocations: Single IRQ static Alloc Test case 12200: Single IRQ Allocations: Single IRQ dynamic Alloc IRQ Range: Command line or default No allocations can be made from user mode. The user mode versions of these tests will fail if any allocations are successful. Since all cases should fail, we must exercise all possible IRQ values. There is no "In Range" test, since this is a subset of the default range. |
14000 14100 14200 |
Test case 14000: Multiple IRQ Allocations: Mult IRQ Static Alloc Test case 14100: Multiple IRQ Allocations: Mult IRQ Dynamic Alloc Test case 14200: Multiple IRQ Allocations: Mult IRQ Force-Static Alloc IRQ Range: Command line or default These test cases randomly generate a set of IRQs for a given call. The IRQs come from the IRQ range (see discussion below). The number of IRQs passed to the IOCTL varies from 1 to the maximum number allowed on the system, as determined by the test. The test tries 100 different allocations for each number of IRQs. In User mode, none of the allocations should succeed. Only the default range is offered, since the command line offers a subset of what should pass |
20010 |
IOCTL_HAL_REQUEST_IRQ: Incorrect Parameter Checks: Bad Input Size IRQ Range: Command line or default Confirm that any size not = sizeof (DEVICE_LOCATION) causes a failure. |
20020 |
IOCTL_HAL_REQUEST_IRQ: Incorrect Parameter Checks: Bad Output Size IRQ Range: Command line or default This IOCTL supports multiple IRQs on output. Bad inputs consist of outputBufSize < 4 bytes. The test code uses random values for the inbound structures, which unfortunately does not provide ideal coverage, since these random values would fail anyway. |
30100 30200 |
IOCTL_HAL_REQUEST_IRQ: Random Request IOCTL_HAL_REQUEST_IRQ: User Specified Params IRQ Range: Command line or default IOCTL_HAL_REQUEST_IRQ is used to hardcode certain DEVICE_LOCATION values to certain IRQs in the platform. This appears to be used only in PCI and serial kitl. The input is a DEVICE_LOCATION structure. The fields in this structure are compared against special cased values in the OAL. The return value is an IRQ. The input space is very large. Every platform seems to use different fields and have different values for these fields. Furthermore, the constants range all over the map. We can’t put any range on them. The "Random Request" test randomly selects values for the fields of the DEVICE_LOCATION structure. The goal is not to find a set of values that work with the IOCTL; rather, it is to try to cause a crash/memory access violation by sending in bad input. The "User Specified Params" test allows the user to pass in values to the IOCTL. These values do not necessarily cause the IOCTL to succeed. This test always passes, since the test has no idea what the user expects to happen with these arguments. To run the second test, call the test with test arguments: -dev IfcType BusNumber LogicalLoc Pin Note that the DEVICE_LOCATION structure also has a PhysicalLoc value. This is a PVOID and is reserved for future use, so is set to zero by our test. In user mode, this test should never succeed. Either test will fail if the IOCTL ever succeeds when run in User mode. |