This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs.

Testing and Debugging

This chapter includes:

• Instrumented kernel trace events
• IDE
• Other methods
• Emergency access to the system

Instrumented kernel trace events

The instrumented kernel emits trace events when:

• a partition's budget changes (including when the partition is created)
• a 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 partition becomes bankrupt

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

IDE (trace events)

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

Other methods

The simplest way to test a system that uses adaptive partitioning 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 "hog" program that loops forever, and start it in each partition. 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.
• Make sure that all latencies are acceptable for your system.
• Use the aps 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-net and qconn in it. Then, if a runaway process ties up the system, you can use the IDE to debug and query the system.
• during deployment -- create a partition and start io-net and inetd in it. If something goes wrong, you can telnet into the system.

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