Testing and Debugging

This chapter includes:

• Instrumented kernel trace events
• Using the QNX IDE
• Using other methods
• Emergency access to the system

Instrumented kernel trace events

The instrumented kernel emits trace events when:

• a scheduler partition's budget changes (including when the partition is created)
• a scheduler partition's name changes (i.e. when the partition is created)
• a thread runs --in wide mode, these events include the partition ID and indicate whether or not the thread is running as critical
• a scheduler partition becomes bankrupt

In addition, all events include the scheduler partition ID and its budget. You can use traceprinter to display the contents of the trace file. You can also use the QNX IDE to parse and display a trace file.

Using the QNX IDE (trace events)

You can--and should--use the System Profiler tool from the QNX IDE to check your system's latencies. For more information about using this tool and the IDE, see the IDE User's Guide.

Using other methods

The easiest method to test a system that uses the thread scheduler is from the command line.

Be sure to test your system in a fully loaded state, because that's where problems are likely to occur. Create a program that consumes resources by looping forever, run it in each partition, and then do the following:

• Watch for bankruptcies, which you should consider to be programming errors. You can use SchedCtl() with the SCHED_APS_BNKR_* flags to control what happens when a partition exhausts its critical budget. This can range from delivering an event to rebooting the system. For more information, see the Neutrino Library Reference.
• Ensure that all latencies are acceptable for your system.
• Use the ap modify command to change your partitions' budgets. The new budgets come into effect at the beginning of the next averaging window. Since the window size is typically 100 ms, you can quickly try many different combinations of budgets.

Emergency access to the system

You can use adaptive partitioning to make it easier to debug an embedded system by providing emergency access to it:

• during development -- create a partition and start io-pkt and qconn in it. Then, if a runaway process ties up the system, you can use the QNX IDE to debug and query the system.
• during deployment -- create a partition and start io-pkt and inetd in it. If you encounter a problem, you can telnet into the system.

In either case, if you don't need to use this partition, the thread scheduler allocates its budget among the other partitions. This provides you with emergency access to the system without compromising performance.