intr -- process a device interrupt


   int prefixintr(void *idata);


The driver's intr( ) entry point routine is called when its device has generated an interrupt, or when another device that shares the same interrupt line has generated an interrupt.


For hardware drivers, a pointer to the device-specific instance data as output by the CFG_ADD subfunction of the config(D2) entry point routine. See ``Device instance'' in HDK Technical Reference.

Return values

The intr( ) routine should return one of the following values to indicate the interrupt status:

The device identified by idata has asserted an interrupt.

The driver cannot tell whether or not its device asserted an interrupt so is assuming that it did.

The device identified by idata did not assert an interrupt.


This entry point is only required for drivers that interface to hardware that interrupts the host computer. It is not used with software-only drivers or with drivers for devices that do not generate interrupts.

The interrupt handler is responsible for determining the reason for an interrupt, servicing the interrupt, and waking up any threads that are blocked waiting for an event associated with the interrupt.

For example, when a disk drive has transferred information to the host to satisfy a read request, the disk drive's controller generates an interrupt. The CPU acknowledges the interrupt and calls the interrupt handler associated with that controller and disk drive. The interrupt routine services the interrupt and then signals completion of the I/O with the biodone(D3) function, which unblocks any threads that are blocked with the biowait(D3) function, waiting on this request. The base-level portion of the driver then conveys the data to the user.

In general, most interrupt routines do the following tasks:

There are also many tasks the intr routine must perform that are driver-type and device specific. For example, the following types of drivers require different functions from their intr routines:

In addition, the functions of an intr routine are device dependent. You should know the exact chip set that produces the interrupt for your device. You need to know the exact bit patterns of the device's control and status register and how data is transmitted into and out of your computer. These specifics differ for every device you access.

The intr routine for an adapter that does not use individual interrupt vectors for each subdevice must access the adapter's status to determine which subdevice generated the interrupt. It must also update the status information, set/clear flags, set/clear error indicators, and so forth to complete the handling of a job. The code should also be able to handle a spurious completion interrupt identified by an empty completion queue. When the routine finishes, it should advance the unload pointer to the next entry in the completion queue.

If the driver blocked with a syncronization primitive in HDK Technical Reference to await the completion of an operation, the intr( ) routine must call an appropriate function to signal the process to resume:

The interrupt routine runs at the interrupt priority level (IPL) in HDK Technical Reference that is associated with the interrupt level for the given device. Lower priority interrupts are deferred while the interrupt routine is active. See spl(D3) for more information.

Context and synchronization

Interrupt context. The driver may not block or access any process state information.

The intr routine must never drop the interrupt priority level below the level at which the interrupt routine was entered or call the uiomove(D3), ureadc(D3), or uwritec(D3) functions when the uio_segflg member of the uio(D4) structure is set to UIO_USERSPACE (indicating a transfer between user and kernel space).

Hardware applicability


Version applicability

ddi: 1, 2, 3, 4, 5, 5mp, 6, 6mp, 7, 7mp, 7.1, 7.1mp, 8, 8mp

Differences between versions

In DDI versions prior to version 8, the syntax of the intr( ) routine is:
   void prefixintr(int ivec);

ivec is a number used by the operating system to associate a driver's interrupt handler with an interrupting device. The makeup and interpretation of ivec is specific to each system implementation. On some systems, this number may be the logical device number, or a combination of logical device and logical controller numbers, used to map the correct interrupt routine with a subdevice. On others, this number could be the interrupt vector number.

For non-loadable or non-autoconfigured DDI versions prior to version 8 that use the mod_drvattach(D3) function to attach interrupts, intr( ) is a named entry point and must be defined as a global symbol with the $entry intr string in the driver's Master(DSP/4dsp) file.

External dependencies

Named entry point routines must be declared in the driver's Master(DSP/4dsp) file. The declaration for this entry point is $entry intr. This applies only to non-STREAMS drivers that use DDI versions prior to version 8.


biodone(D3), biowait(D3), spl(D3), SV_BROADCAST(D3), SV_SIGNAL(D3), SV_WAIT(D3), SV_WAIT_SIG(D3), wakeup(D3)

intr(D2mdi), intr(D2sdi)

``Interrupts'' in HDK Technical Reference
``Interrupt handlers, attaching and registering'' in HDK Technical Reference

19 June 2005
© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005