Priority levels

The SPARC CPU has 16 priority levels, ranging from zero to fifteen. Level 0 is where user code executes: anything can interrupt users. Level 1 is sometimes known as "softclock" ” the level at which the kernel does time-based housekeeping functions. This is a low enough priority that any hardware needing attention can get it: all devices interrupt at a higher level. The highest level of priority (15) is used to mask out everything except the highest level of interrupt, usually associated with a system shutdown or (in the case of the SPARCserver 1000 and SPARCcenter 2000) a potentially dangerous overheating condition.

SBus and VME peripheral devices have only seven levels of interrupt priority (and usually use only about four of them). These are mapped to internal CPU priority levels by hardware according to the following table.

Table 28-1. SBus and VME device interrupt priorities

CPU Priority	Interrupt/Device
Level 0	Spurious
Level 1
Level 2	SBus/VME level 1
Level 3	SBus/VME level 2
Level 4	On-board SCSI devices
Level 5	SBus/VME level 3
Level 6	On-board Ethernet
Level 7	SBus/VME level 4
Level 8	On-board video (retrace)
Level 9	SBus/VME level 5
Level 10	Normal clock (100 Hz)
Level 11	SBus/VME level 6, floppy drive
Level 12	Serial I/O (ZS)
Level 13	SBus/VME level 7, audio device
Level 14	High-level clock (kernel profiling
Level 15	Asynchronous error (memory errors)

Devices that interrupt at SBus/VME level 2 or 3 are normally disk or tape devices (the IPI disk controller, for example, interrupts at level 2). Bus level 4 is used for the somewhat smart ALM-2 serial I/O card; this does have some buffering capability and does not need attention quite as promptly.

Unfortunately, the mappings are not linear or consistent, but at least they are in order.

Note the difference between disk/tape and character input. Generally, any response to a CPU request is a low priority; it's just informative. Any unsolicited input occurs at a fairly high priority, since more may be arriving at any time. Also, unsophisticated hardware is generally handled at a higher priority, partly because the smarter stuff can take care of itself and requires little attention from the main processor.

For several reasons, the high-priority interrupt service routines are generally very restricted in what they can do. First, since they will most likely block out other requests that might occur at the same time or while the service routine is executing, they need to do their thing and get out fast. Second, since they may be associated with devices that are fairly high speed, they must avoid doing any extensive time-consuming processing or they will lose succeeding interrupts and possibly data. As a general rule, interrupt service functions, regardless of their priority, will do little more than save data in a safe place, signal some other function that the data is there, and possibly start up the next device request if one is pending.