| Title |
How to use Trace to log system events. |
| Ref. No. |
QNX.000009312 |
| Category(ies) |
Utilities, Development |
| Issue |
My system keeps locking up, and try as I might, I can't figure out why. I do have a suspect-an application that handles interrupts. The lockups started happening after I added this app to my sysinit file. But with the system locking up, how can I find out if this app is really the problem? |
| Solution |
With QNX4.2, we introduced a trace facility that logs system events, even those from interrupt handlers. To see if your interrupt handler is operating as expected, you can log the events it generates, using Trace calls.
To give you an idea how you could use the trace facility in your program, let's look at the following:
•x09invoking a trace call
•x09setting the trace buffer
•x09setting the severity level for logging trace events
•x09printing trace events
Invoking a trace call
x09Here's an example interrupt handler in which I've placed a call to a Trace function:
/* The hardware interrupt handler */
#pragma off( check_stack );
pid_t far handler()
{
x09unsigned char c;
x09c = inp(port); /* read in a byte from a port */
x09Trace1(_TRACE_TEMPORARY, _TRACE_TESTING, (int)c);
x09return(0);
}
#pragma on( check_stack );
x09Every time this interrupt handler runs, the Trace1 call will log an event with the data that the inp call reads from the port. Trace1 takes a code argument that indicates the type of event; normally you use a unique code that you obtain from QNX Software Systems. In this case, I've specified _TRACE_TEMPORARY, the default code you use until you obtain your unique code. Trace1 also takes a severity argument, which assigns a level of importance to the trace event. In this case, I've specified -TRACE_TESTING, which is the severity level used for debugging. This predefined value indicates that the trace entry was simply a test for your application, not an actual error.
Setting the trace buffer
x09The Process Manager (Proc) maintains a special buffer for trace events. By default, this buffer is 2K. Normally this is sufficient, but to run the above interrupt handler, you'd first need to increase the size of the buffer. That's because the handler would log a trace event every time it executed, whether or not a problem occurred.
x09To increase the size of the trace buffer, you add a larger -T option to Proc in the nodes build image, rebuild the image, then reboot. For more information on this procedure, see the chapter on "Building a Custom Operating System Image" in the QNX 4 User's Guide.
Setting the severity level
x09The trace buffer can log seven levels of events, from the least critical (severity level 7) to the most critical (severity level 0). By default, the buffer only logs events of severity levels 5 to 0. To log events from the above handler, you'd need to extend this default range since the _TRACE_TESTING argument equals severity level 7. To do this, you can use the tracectrl utility (e.g. tracectrl -s 7)
Printing trace events
x09Once you've made the appropriate changes to the trace buffer and to the severity level, you could run the interrupt handler program for a while, then stop it. The trace events would be logged with the _TRACE_TEMPORARY code, which is Oxfffff. (See </usr/include/sys/trace.h> for severity levels and trace-event formats and </usr/include/sys/tracecod.h> for definitions of the various trace codes.)
x09To see all trace events in raw form, you'd type traceinfo. To see only the trace events that the interrupt handler generated, you could type traceinfo -M Oxfffff. Note that traceinfo also has a -m option that prints a millisecond timestamp after the displayed date.
x09You can control how traceinfo prints events by creating a format string to match the trace events you're generating. For example, you could create a file called tracetesting that contains the following lines:
x09#major Oxfffffx09 /* Trace Temporary */
x090 Input from port is 0x%x
x09You could then tell traceinfo to use this file for processing the trace events. For example, if you entered:
x09traceinfo -M Oxfffff -m -e tracetesting
the output would look something like this:
Feb 15 11:48:53.189 7 fffff000 Input from port is 0x29
Using traceinfo's formatting commands, you can make very sophisticated logs of what's happening in your application.
For more information, see traceinfo, tracectrl, and tracelogger in the Utilities Reference Supplement. See also the Trace Functions entry in the WATCOM C Library Reference.
|
|
