Interrupts in tracebacks


An interrupt is just another form of trap, so any interrupt response is going to operate the same way something like a page fault would. A special trap frame is stored on the stack, and an interrupt service routine is called from the vector. This function then polls various pieces of hardware at that interrupt level.

You can usually identify an interrupt by noticing a driver interrupt service function on the stack. These almost universally end in "int" or "intr," so something like zsint() would refer to the interrupt service function for the ZS device driver. Just before this in time (just below it on the stack trace), you should find a low-level assembly function that does the polling. Look for something like level10() as a function name , which would correspond to interrupt priority level 10 processing. Just below this on the stack will appear the stack frame that contains the PC / nPC values from the code being executed when the interrupt occurred.

Some interrupt priority levels are devoted to one device, just as if it were a real vectored interrupt system. This means the kernel software need not poll; it knows exactly which device caused the interrupt. The clock is the main device for which this is done, since the great frequency of clock interrupts (100 per second) demands efficiency in handling them. The function that handles the high-priority clock hardware "tick" is normally known as "hardclock"; "softclock" is the lower-priority housekeeping function invoked by hardclock when and if there is something to be done that is time-based (required periodically or after a certain elapsed time). This could include STREAMS service procedures, character data handling, callback functions (also known as callout functions), or signal generation, such as alarm clock signals delivered to user programs.

Callout functions are also known as delay functions or deadman timers; a driver or kernel routine will request that a function be invoked after a certain amount of time has passed. This may be a cleanup function, to be called if a device has not answered within a certain period of time, or merely some sort of delay function to send certain data out after a specified time has elapsed.

For an example of an interrupt from the keyboard appearing in a traceback, look at the third case study, "Hanging Instead of Swapping", which examines a hung system. In this case, recognition of the L1-A stop sequence appears on the top part of the stack. The interrupt itself occurred during the idle function; the trap frame contains a PC and nPC value from within that routine.



PANIC. UNIX System Crash Dump Analysis Handbook
PANIC! UNIX System Crash Dump Analysis Handbook (Bk/CD-ROM)
ISBN: 0131493868
EAN: 2147483647
Year: 1994
Pages: 289
Authors: Chris Drake

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net