Chapter 5. Event Dictionary

Chapter 5. Event Dictionary
Prev		Next

This chapter provides the following sections:

“Using the Event Dictionary” explains how to make sense of the event dictionary.
“Event Dictionary” shows various events that IRIXview collects.

Using the Event Dictionary

This section provides tips for understanding entries in the event dictionary. The event dictionary is a catalog of events collected by IRIXview, listing each event by object type, providing the following information for each one:

the event's icon
possible causes of the event
the possible process state effects that can result from the event
information collected about the event (that is, information displayed when you drag the event's icon into the Event Inspector window; see “Using the Event Inspector” for details.)

Figure 5-1. Signal Receive Icon

Suppose you are viewing an event log with the IRIXview main window and you see the Signal Receive event icon, as shown in Figure 5-1.

Look in the Legend window (see “Context Legend Window”) to determine that this is the Signal Receive event icon.
Using the event dictionary in this chapter, look up the information on what can cause a Signal Receive event, what effect on process state it may have, and what information is collected for a Signal Receive event.

Figure 5-2 shows the structure of a typical entry in the event dictionary.

Figure 5-2. Sample Event Dictionary Page

Most of the elements that are called out on the sample page are self-explanatory, with the possible exception of the event table, which presents a definition of the information collected about the event.

The event table describes the information that is logged for a particular event.

Looking at the sample Signal Receive event dictionary page above, you see the context (the process, ISR, or idle thread in which the event occurred) and the eventName. You also see that the timeStamp is logged. For information on starting event logging, see Chapter 2, “Collecting Event Data.”

For example, if you drag the Signal Receive icon into the Event Inspector window, you see something like this:

TSTAMP_EV_SIGRECV: 
      0.2947S[1]          tcsh:received signal SIGCLD
      (handler 0x1001dc6c)

This provides the following information:

A Signal Receive event occurred (internal event type TSTAMP_EV_SIGRECV).
The second line indicates the time (in seconds) since tracing began (0.2947).
tcsh: indicates the process name that received signal SIGCLD
the final line specifies the signal handler number (0x1001dc6c).^[1]

Note: If an invalid parameter is passed to a routine, the event icon may not appear, depending on whether the error was detected before or after event logging occurred. In particular, if an invalid object ID is passed to a routine, the event icon will not appear.

Event Dictionary

The event dictionary is organized into the following sections:

“Interrupt Service Routine (ISR)” describes interrupt events.
“Signal” describes software signal and termination events.
“Processes” describes process deletion events.
“Unknown” describes events that cannot be classified.
“User Event” describes non-kernel process events.

Interrupt Service Routine (ISR)

The two interrupt events are Interrupt Entry for start and Interrupt Exit for transition.

Interrupt Entry—Entry to ISR

Figure 5-3. Interrupt Entry Icon Possible causes:		A hardware interrupt occurred for which there is an associated ISR.
Process state effects:		If the interrupt occurs in the context of an executing process, the process is displayed as making a transition to the ready state when the ISR starts executing.

In IRIX, there is a single global interrupt entry point for each processor. With irixview, this global entry point appears in a Context View graph as interrupt 0 ([x] Int 1st Level 0). All interrupts received by a processor pass through this global entry point. Each interrupt may be further qualified by other kernel events that appear in the Context View graph as additional interrupts. A description of interrupts is provided in Table 5-3.

Note: This icon is displayed by default. To suppress this icon, toggle the Interrupts button in the Display Events/States window.

Table 5-1 presents the information collected for the event Interrupt Entry.

Table 5-1. Information Collected for Interrupt Entry Events

Event Parameter	Sample Data	Description
timeStamp	`0.0532S[0]`	The time at which the event occurred.
context	`CPU counter interrupt entry`	Context in which the event occurred.
eventName	`TSTAMP_EV_CPUCOUNTER_INTR`	The name of the event associated with this icon.

Interrupt Exit—Exit From ISR

Figure 5-4. Interrupt Exit Icon Possible causes:		The ISR finished executing.
Process state effects:		When this ISR finishes executing, control returns to the interrupted context.

Note: The display of this icon is suppressed by default. To display this icon, toggle the Interrupts button in the Display Events/States window.

Table 5-2 presents the information collected for the event Interrupt Exit.

Table 5-2. Information Collected for Interrupt Exit Events

Event Parameter	Sample Data	Description
timeStamp	`0.0532S[0]`	The time at which the event occurred.
context	`CPU counter interrupt exit`	Context in which the event occurred.
eventName	`TSTAMP_EV_INTREXIT`	The name of the event associated with this icon.

Interrupt Types

The following interrupts are identified by IRIXview. Each interrupt is delineated by an interrupt entry and interrupt exit timestamp.

Table 5-3. Interrupts Defined for IRIXview

Interrupt Level	Description	Probable Cause
Int 1st Level (0)	Interrupt qualifier	All interrupts that occur under IRIX “pass through” this level. Some interrupts are not further qualified by IRIXview (for example, `vsync` and VME interrupts) and appear at this level only.
Int Level 1 (1)	Frame Scheduler Interrupt	This is a further qualified version of the CC counter interrupt (see Int 7) indicating that the Frame Scheduler interrupted the processor.
Int User Level (4)	User-Level Interrupt	By default IRIX uses no user-level interrupts. This interrupt appears only on systems where users have provided ULIs; see `uli(3)`.
Int CPU Yield (5)	Frame Scheduler yield	Not actually an IRIX interrupt, this level indicates that a user process has called either the `frs_yield()` function or the `schedctl()` (MPTS_FRS_YIELD) system call.
Int CPU Ctr (6)	CPU tick interrupt	The IRIX scheduler interrupts each processor every 10 milliseconds. IRIX uses this interrupt to perform scheduling processes and other housekeeping functions.
Int RTC Ctr (7)	CC counter interrupt	An event timeout interrupt, either from expiration of a kernel-initiated timer or a user-initiated timer (ITIMER).
Int Prof Ctr (8)	Profiler interrupt	An interrupt initiated from either the profiler (see prof(1)) or the built-in audio hardware.^[a]
Int Group (9)	Group interrupt	Designates interrupt occurring on IRIX multiprocessor systems. Group interrupts are seen when multiple Frame Schedulers are synchronized across multiple processors.
Int Inter-CPU (11)	Inter-processor interrupts	One processor has interrupted another based on some action initiated by the first processor (for example, TLB flush, TLB fault, and so forth).
Int Network (12)	Network interrupts	Some network drivers, such as the Challenge ethernet driver, provide this interrupt event.
^[a]Note that on systems with built-in audio (such as the O2, Octane, and Onyx2) a profiler interrupt occurs every millisecond, even when no audio is being played or recorded.

Signal

The two signal events are Signal Receive for entry and Signal Send for termination.

Signal Receive—Entry to Signal Handler

Figure 5-5. Signal Receive Icon Possible causes:		The application code or an ISR sent a signal with the `kill()` or the `sigqueue()` routine and a signal handler was entered. The application code sent a signal with the `raise()` routine and a signal handler was entered.
Process state effects:		The signalled process is interrupted and the signal handler runs in that process' context.

Table 5-4 presents the information collected for the event Signal Receive:

Table 5-4. Information Collected for Signal Receive Events

Event Parameter	Sample Data	Description
timeStamp	`2.5348S[0]`	The time at which the event occurred.
context	`tcsh: received signal SIGCLD`	Context in which the event occurred.
eventName	`TSTAMP_EV_SIGRECV`	The name of the event associated with this icon.
handler	`(handler 0x1001dc6c)`	The signal handler number.

Signal Send—Send Signal to a Process

Figure 5-6. Signal Send Icon Possible causes:		Application code or an ISR sent a signal to the specified process with the `kill()` or `sigqueue()` routine. Application code sent a signal to the calling process with the `raise()` routine.
Process state effects:		A process receives a pending signal the next time the process exits from the kernel domain. For most signals, this could occur: when the process is dispatched after a wait or preemption upon return from some system call upon return from the kernel's usual 10-millisecond tick interrupt at the start of a minor frame, under the Frame Scheduler

SIGALRM is delivered as soon as the kernel is ready to return to user processing after the timer interrupt, to preserve timer accuracy. Thus, for a process that is ready to run, in a processor that has not been made nonpreemptive, normal signal latency is at most 10 milliseconds and SIGALRM latency is less. However, when the receiving process is not ready to run, or when there are competing processes with superior priorities, the delivery of a signal is delayed until the next time the receiving process is scheduled.

Table 5-5 presents the information collected for the event Signal Send.

Table 5-5. Information Collected for kill Events

Event Parameter	Sample Data	Description
timeStamp	`2.5344S[1]`	The time at which the event occurred.
context	`x: was sent signal SIGTSTP`	Context in which the event occurred.
eventName	`TSTAMP_EV_SIGSEND`	The name of the event associated with this icon.
processID	`mediad (5807)`	PID of the process to receive the signal.

Processes

The process event is Exit Process for process termination.

Fork Process—Spawn a Process

Figure 5-7. Fork Process Icon Possible causes:		The system or application code called the `fork()` routine.
Process state effects:		The parent process usually executes another image by means of the `exec()` routine, and a context switch occurs.

Table 5-6 presents the information collected for the event Fork Process.

Table 5-6. Information Collected for processCreate Events

Event Parameter	Sample Data	Description
timeStamp	`1.6621S[0]`	The time at which the event occurred.
context	`rlog: process fork`	The context in which the event occurred.
eventName	`TSTAMP_EV_FORK`	Name of the event associated with this icon.

Exit Process—Delete a Process

Figure 5-8. Exit Process Icon Possible causes:		The system or application code received a signal with the action to terminate the process, or the application code called the `exit()` routine.
Process state effects:		If the routine is successful, the specified process is terminated. If the executing process kills itself, a context switch occurs.

Table 5-7 presents the information collected for the event Exit Process.

Table 5-7. Information Collected for processDelete Events

Event Parameter	Sample Data	Description
timeStamp	`1.6621S[0]`	The time at which the event occurred.
context	`rlog: process exit`	The context in which the event occurred.
eventName	`TSTAMP_EV_EXIT`	Name of the event associated with this icon.

Process Events

Table 5-8 shows the various process events icons in IRIXview.

Table 5-8. Process Event Icons

Process Event Type	Event Icon	Numeric Range
Net Event		K400-K499
Disk Event		K300-K399
Profile Event		K18, K19
Miscellaneous Kernel Event
Virtual Memory Event		K100-K199
System Call Begin Event		K22
System Call End Event		K23
Memory Allocate Event		K28

Unknown

Unknown Event—Unknown Event

Figure 5-9. Unknown Event Icon Possible causes:		IRIXview has received an event that it does not recognize.
Process state effects:		Indeterminate.

Table 5-9 presents the information collected for the event unknown:

Table 5-9. Information Collected for Unknown Events

Event Parameter	Sample Data	Description
UnknownId	`TSTAMP_UNKNOWN`	The ID of the event.

User Event

DefaultUser—Display User-specified Event

Figure 5-10. Default User Icon Possible causes:		The application code called the `rtmon_log_user_tstamp()` function.
Process state effects:		None.

Table 5-10 presents the information collected for the event defaultUser:

Table 5-10. Information Collected for defaultUser Events

Event Parameter	Sample Data	Description
timeStamp	`1.6621S[0`	The time at which the event occurred.
context	`myapp: entering myfunction()`	Context in which the event occurred.
userEventId	`TSTAMP_USER_EVENT`	The name and number of the user event.
address	`0x1a644`	The address at which the event-point was set.

Other information may be collected based on the passing of parameters to the rtmon_log_user_tstamp() routine. See the rtmon_log_user_tstamp(3) man page or “Adding Timestamps to Your Program” for more information.

Many IRIX kernel events are shown as “user” events—or, more accurately, user event numbers above 20000 are reserved for kernel events. These events are unique to IRIXview and are described in Table 5-11. In the table, IRIX REACT/Pro Frame Scheduler is designated as FRS for convenience.

Note: For online use, see the Legend window for icon pictures and explanations.

Table 5-11. REACT/Pro Events and Event Numbers

Event Number and Icon	Description	Possible Cause
K0	Undefined system event	An event (timestamp) of an unknown type was generated from the IRIX kernel.
K1	Undefined daemon event	An event (timestamp) of an unknown type was generated from an IRIX daemon.
K2	FRS dispatch	The FRS chooses a new process to run, or idles the processor if no other FRS processes are ready to run.
K3	FRS yield	A user process has called either the `frs_yield()`function or the `schedctl` (MPTS_FRS_YIELD) system call. This event generally appears with INT 5.
K4	FRS fatal frame overrun	The FRS has incurred a frame overrun (indicates that a process failed to yield in a minor frame) and there is no recovery mechanism in place.
K8	FRS frame underrun	The FRS has incurred a frame underrun (indicates that a process should have been dispatched in a minor frame and was not). Qualifier #2 returns the current number of underruns.
K9	FRS frame overrun	The FRS has incurred a frame overrun (indicates that a process failed to yield in a minor frame). This event is accompanied with either event 20010, 20011, 20012, or 20013. Qualifier #2 returns the current number of overruns.
K10	FRS no recovery	No recovery mechanism is in place upon an overrun condition (this event is always accompanied by event 20009).
K11	FRS inject frame	An FRS minor frame has been injected as the recovery mechanism for a frame overrun occurrence (this event is always accompanied by event 20009).
K12	FRS stretch frame	An FRS minor frame has been stretched as the recovery mechanism for a frame overrun occurrence (this event is always accompanied by event 20009).
K13	FRS steal frame	An FRS minor frame has stolen time from an adjacent frame as the recovery mechanism for a frame overrun occurrence (this event is always accompanied by event 20009).
K14	FRS maximum errors	The FRS has received the maximum number of allowable errors (overruns or underruns) permitted by the application or program. This event causes the FRS to terminate.
K15	Dropped timestamps	In some extreme circumstances, the `rtmond` daemon issues this event to indicate that timestamps have been dropped from the event stream (this could occur, for example, when events are being generated faster than they can be saved).
K16	FRS start of major frame	Designates the start of a Frame Scheduler major frame.
K17	FRS start of minor frame	Designates the start of a Frame Scheduler minor frame.

^[1]A unique event ID is assigned to each event in the log. This is to differentiate between a process of a particular ID that is deleted and a new process spawned with the deleted process's ID.

Prev	Table of Contents	Next
Chapter 4. Inspecting and Analyzing Data		Chapter 6. User Interface Reference