Patent Publication Number: US-6983337-B2

Title: Method, system, and program for handling device interrupts

Description:
BACKGROUND OF THE INVENTION 
   1. Field of the Invention 
   The present invention relates to a method, system, and program for handling device interrupts. 
   2. Description of the Related Art 
   In many operating systems, such as Microsoft Windows®, Linux®, Unix®, etc. multiple devices may communicate over a bus interface with the operating system interrupt service routine (ISR) using a single interrupt line. (Microsoft and Windows are registered trademarks of Microsoft Corporation, Linux is a registered trademark of Linus Torvalds, UNIX is a registered trademark of The Open Group). One of multiple devices using an interrupt line, would assert an interrupt on the bus to the interrupt line assigned to that device to request or transmit data to the operating system. The operating system would further execute various device driver programs that provide a software interface between the operating system and the device. A device driver includes device specific commands to communicate with and control one attached device. Upon receiving a device interrupt, the operating system ISR would poll each device driver interrupt service routine (ISR) running in the operating system to identify the device driver ISR associated with the device that asserted the interrupt. 
   In response to receiving the polling request from the operating system ISR asking the device driver ISR whether the interrupt is from the device driver&#39;s device, the device driver ISR communicates with the associated device and reads an interrupt status register in the device to determine whether the driver&#39;s device sent the interrupt request. In Microsoft® Windows® operating systems, if the driver&#39;s device status registers indicate that the device did send an interrupt request, then the device driver ISR responds to the operating system ISR by claiming the interrupt and requesting a deferred procedure call (DPC) to process the device request that is the subject of the interrupt request. In operating systems other than Windows, such as Linux® and Unix®, upon claiming the interrupt, the device driver ISR does not issue a request for a DPC and instead directly performs the work. The device driver will further write to the device&#39;s mask register to disable the device&#39;s interrupts to cause the device to deassert the interrupt request line and will separately write the read interrupt status to the device&#39;s interrupt status register to acknowledge the device&#39;s interrupt. If a device driver ISR responds that the interrupt is not from the device associated with the driver, then the operating system ISR determines a next device driver in a chain of device drivers to poll and sends the request to the next device driver ISR in the chain. The operating system ISR continues polling device driver ISRs in the list until one device driver ISR claims the interrupt and requests DPC resources. 
   When the device driver ISR reads the device status registers to determine whether the driver&#39;s device generated the interrupt, the processor must delay processing until the device register is read and the device driver ISR responds to the polling request. Reading a device status register over an I/O bus may take a relatively significant amount of time, thus increasing the latency of the device driver ISR operations, which in turn reduce processor performance. 
   For these reasons, there is a need in the art to provide improved techniques for handling device interrupt requests. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     Referring now to the drawings in which like reference numbers represent corresponding parts throughout: 
       FIG. 1  illustrates a computing environment in which aspects of the invention are implemented; 
       FIG. 2  illustrates flags set by a device driver in response to determining whether the associated device transmitted the interrupt in accordance with described implementations of the invention; 
       FIG. 3  illustrates operations performed by the operating system to handle an interrupt request in accordance with described implementations of the invention; 
       FIG. 4  illustrates operations performed by the device driver to handle an interrupt request in accordance with described implementations of the invention. 
       FIG. 5  illustrates an alternative computing environment in which further aspects of the invention are implemented; 
       FIGS. 6 and 7  illustrate operations performed in a device to generate an interrupt signal in accordance with implementations of the invention; 
       FIGS. 8 ,  9  and  11  illustrate operations performed by the device driver to handle an interrupt request in accordance with described implementations of the invention; and 
       FIG. 10  illustrates an alternative implementation of the device and status registers in accordance with described implementations of the invention. 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
   In the following description, reference is made to the accompanying drawings which form a part hereof and which illustrate several embodiments of the present invention. It is understood that other embodiments may be utilized and structural and operational changes may be made without departing from the scope of the present invention. 
   Interrupt Polling of Device Drivers 
     FIG. 1  illustrates a computing environment in which aspects of the invention may be implemented. A computer  2  includes one or more central processing units (CPUs)  4 , a volatile memory  6 , a bus interface  8  on which devices communicate data and interrupts to the computer  2 . A plurality of devices  10   a ,  10   b  . . .  10   n  communicate data and interrupts to the computer  2  via a bus interface  8 . The bus interface  8  may be implemented using any Input/Output (I/O) bus technology known in the art, such as the Peripheral Component Interconnect (PCI), Industry Standard Architecture (ISA), the Video Electronics Standards Association (VESA), Micro Channel Architecture (MCA), Extended ISA, and any other known bus technology known in the art. The devices  10   a ,  10   b  . . .  10   n  may comprise any I/O device known in the art, such as storage devices (e.g., tape drive, hard disk drive, optical disk drive, memory card reader, etc.), network adaptor card, video devices, printers, etc. The devices  10   a ,  10   b  . . .  10   n  include one or more status registers  14   a ,  14   b  . . .  14   n  that indicate, among other things, whether the device has asserted an interrupt on the bus  8 . Although  FIG. 1  only shows one bus  8 , the computer  2  may include multiple busses to enable communication with the devices connected to such additional busses. 
   The computer  2  further includes an operating system  12 , which may comprise any operating system known in the art, such as a Microsoft Windows® operating system, Linux®, a Unix® type operating system, etc. A bus driver  15  comprises a program that provides an interface between the operating system  12  and the bus  8  to enable communication between the operating system  12  and the devices  10   a ,  10   b  . . .  10   n  that communicate on the bus  8 . The operating system  12  includes an interrupt service routine (ISR) component  16  that handles interrupt requests received from the devices  10   a ,  10   b  . . .  10   n  transmitted across interrupt lines (not shown) of the bus  8 . The operating system  12  further loads into memory  6  and executes one device driver  18   a ,  18   b  . . .  18   n  for each device  10   a ,  10   b  . . .  10   n  recognized by the operating system  12 . The device drivers  18   a ,  18   b  . . .  18   n  each include device specific code to enable communication between the operating system  12  and the devices  10   a ,  10   b  . . .  10   n . The device drivers  18   a ,  18   b  . . .  18   n  each include an interrupt service routine (ISR)  20   a ,  20   b  . . . .  20   n  component to handle interrupt requests from the associated device  10   a ,  10   b  . . .  10   n . The operating system ISR  16  utilizes a device driver list  22  that identifies all the loaded device drivers  18   a ,  18   b  . . .  18   n  registered with the operating system  12 . 
   Further, in Microsoft® Windows® operating systems, the operating system ISR  16  may assign a deferred procedure call (DPC)  24   a ,  24   b  . . .  24   n  to a device driver  18   a ,  18   b  . . .  18   n  to perform device related work. In non-Windows® operating systems, there is no DPC. 
     FIG. 2  illustrates data that the device driver ISR  20   a ,  20   b  . . .  20   n  communicates to the operating system ISR  16  in response to an interrupt polling request. A request DPC flag  30  indicates whether the device driver ISR  20   a ,  20   b  . . .  20   n  is requesting a DPC  24   a ,  24   b  . . .  24   n  to handle device interrupt related work. A claim interrupt flag  32  indicates whether the device driver  18   a ,  18   b  . . .  18   n  is claiming the interrupt after determining that the interrupt was generated by the driver&#39;s device  10   a ,  10   b  . . .  10   n.    
     FIG. 3  illustrates operations performed by the code of the operating system ISR  16  to handle an interrupt from a device  10   a ,  10   b  . . .  10   n . Control begins at block  100  with the operating system ISR  16  receiving an interrupt from one device  10   a ,  10   b  . . .  10   n  over the bus  8 . In response, the operating system ISR  16  performs (at block  102 ) a context switch to interrupt handling mode. The operating system ISR  16  then determines (at block  106 ) from the device driver list  22  the first listed device driver and calls (at block  108 ) the determined device driver ISR  20   a ,  20   b  . . .  20   n  to poll whether the device managed by the determined device driver  18   a ,  18   b  . . .  18   n  initiated the interrupt. Control then proceeds to block  150  in FIG.  4 . 
     FIG. 4  illustrates operations performed by code of the device driver ISRs  20   a ,  20   b  . . .  20   n  in response to receiving (at block  150 ) the call from the operating system ISR  16  generated at block  108 . In response, the device driver ISR  20   a ,  20   b  . . .  20   n  sets (at block  152 ) the request DPC  30  and the claim interrupt 32 flags ( FIG. 2 ) to “off”. The called device driver ISR  20   a ,  20   b  . . .  20   n  then issues (at block  154 ) a read request over the bus  8  to read the device interrupt status register  14   a ,  14   b  . . .  14   n  of the driver&#39;s device  10   a ,  10   b  . . .  10   n . If the read status register  14   a ,  14   b  . . . n indicates (at block  156 ) that the driver&#39;s device  10   a ,  10   b  . . .  10   n  submitted an interrupt request, then the called device driver ISR  20   a ,  20   b  . . .  20   n  writes (at block  160 ) to the device status register  14   a ,  14   b  . . .  14   n  to clear the interrupt and writes to the mask register to disable the interrupt. Disabling the interrupt by writing to the mask register prevents the device  10   a ,  10   b  . . .  10   n  from generating any further interrupts. The device driver ISR  20   a ,  20   b  . . .  20   n  then sets (at block  162 ) the request DPC flag  30  to “on” and leaves the claim interrupt flag  32  (FIG.  2 ) “off” and responds (at block  164 ) with the flags  30  and  32  to the operating system ISR  16  that called the device driver ISR  20   a ,  20   b  . . .  20   n.    
   If (at block  156 ) the device  10   a ,  10   b  . . .  10   n  did not send an interrupt, then the device driver ISR  20   a ,  20   b  . . .  20   n  determines (at block  158 ) whether there is work to do not necessarily related to an interrupt. The work that is determined may or may not relate to a device interrupt. For instance, the device driver ISR  20   a ,  20   b  . . .  20   n  may read descriptors of packets to determine whether the device  10   a ,  10   b  . . .  10   n  may soon send an interrupt. Additionally, to determine whether there is available work to perform, the device driver ISR  20   a ,  20   b  . . .  20   n  may read a register that counts a number of packets, where the number of packets may indicate that there is work to perform. Other techniques may be used to anticipate any work that may be performed in the near future which will require DPC resources. In this way, the device driver ISR  20   a ,  20   b  . . .  20   n  submits a request for a DPC resource as part of an opportunistic search for anticipated work or interrupts that are likely to be generated. Implementations that require DPC resources concern the Microsoft® Windows® operating system. However, certain non-Windows operating systems do not utilize DPCs, and in such systems, the device driver ISR  20   a ,  20   b  . . .  20   n  performs the work itself without requesting a DPC. In such non-Windows implementations, the device driver ISR may respond by not claiming the interrupt and then proceeding to perform the work. 
   This opportunistic determination saves resources because an interrupt message is avoided by handling the work before the interrupt is requested. Further, the described implementations conserve operating system resources because a context switch to interrupt handling mode is avoided. If (at block  158 ) there is no anticipated work, control proceeds to block  164  to transmit the flags  30 ,  32  ( FIG. 2 ) that are both set in the “off” state. 
   With respect to  FIG. 3 , the operating system ISR  16 , upon receiving (at block  110 ) the response from the device driver ISR  20   a ,  20   b  . . .  20   n , determines (at block  112 ) whether the DPC request flag  30  is “on”, indicating the device driver ISR  20   a ,  20   b  . . .  20   n  is requesting a DPC. If so, the operating system ISR  16  assigns (at block  114 ) DPC resources  24   a ,  24   b  . . .  24   n  to the responding device driver ISR  20   a ,  20   b  . . .  20   n . From the no branch of block  112  or block  114 , control proceeds to block  116  where the operating system ISR  16  determines whether the responding device driver ISR  20   a ,  20   b  . . .  20   n  claimed the interrupt, i.e., whether the claim interrupt flag  32  ( FIG. 2 ) is “on”. If so, then the operating system ISR  16  acknowledges (at block  118 ) the system interrupt and then context switches (at block  120 ) out of the interrupt handling mode. If (at block  116 ) the responding device driver ISR  20   a ,  20   b  . . .  20   n  did not claim the interrupt and if (at block  122 ) there are further device drivers  18   a ,  18   b  . . .  18   n  not yet checked on the device driver list  22 , then the next device driver on the list  22  is determined (at block  124 ) and control proceeds to block  108  to call that next determined device driver ISR  20   a ,  20   b  . . .  20   n  to check whether the device managed by that next determined device driver ISR  20   a ,  20   b  . . .  20   n  initiated the interrupt. If (at block  122 ) there are no further device drivers on the list  22 , then control proceeds to block  118  to end the interrupt handling. 
   With the described implementations, the device driver ISRs  20   a ,  20   b  . . .  20   n  claim an interrupt by requesting a DPC  24   a ,  24   b  . . .  24   n , but not formally claiming the interrupt to the operating system ISR  16 . This causes the operating system ISR  16  to assign the claiming device driver ISR  20   a ,  20   b  . . .  20   n  sufficient DPC  24   a ,  24   b  . . .  24   n  resources to service the interrupt. However, because the interrupt was not claimed, the operating system ISR  16  continues to check device drivers in the list  22 , thereby allowing the operating system ISR  16  to handle a subsequent interrupt request for a device driver  10   a ,  10   b  . . .  10   n  lower down the list  22  without having to utilize processor resources to context switch to interrupt handling mode. Further, with the described implementations, the device driver ISR  20   a ,  20   b  . . .  20   n  may anticipate work to perform and request DPC resources  24   a ,  24   b  . . .  24   n  even when the driver&#39;s device did not initiate the interrupt in order to handle an anticipated interrupt request from the device  10   a ,  10   b  . . .  10   n  in a manner that relieves the operating system ISR  16  of the burden of having to handle the interrupt, thereby further conserving operating system resources. 
   Maintaining Device Interrupt Status Registers in Local Memory 
     FIG. 5  illustrates an alternative implementation of the computing environment of FIG.  1 . In  FIG. 5 , a computer  202  includes one or more central processing units (CPU)  204 , a volatile memory  206 , a bus interface  208  on which devices communicate data and interrupts to the computer  202 . A plurality of devices  210   a ,  210   b  . . .  210   n  communicate data and interrupts to the computer  202  via the bus  208 . The bus  208  may be implemented using any Input/Output (I/O) bus technology known in the art, such as the Peripheral Component Interconnect (PCI), Industry Standard Architecture (ISA), the Video Electronics Standards Association (VESA), Micro Channel Architecture (MCA), Extended ISA, and any other known bus technology known in the art. The devices  210   a ,  210   b  . . .  210   n  may comprise any I/O device known in the art, such as storage devices (e.g., tape drive, hard disk drive, optical disk drive, memory card reader, etc.), network adaptor card, video devices, printers, etc. The devices  210   a ,  210   b  . . .  210   n  include one or more status registers  214   a ,  214   b  . . .  214   n  that indicate, among other things, whether the device has asserted an interrupt on the bus  208 . Although  FIG. 5  only shows one bus  208 , the computer  202  may include multiple busses to enable communication with the devices connected to such additional busses. 
   The computer  202  further includes an operating system  212 , which may comprise any operating system known in the art, such as a Microsoft Windows® operating system, Linux®, a Unix® type operating system, etc. A bus driver  215  comprises a program that provides an interface between the operating system  212  and the bus  208  to enable communication between the operating system  212  and the devices  210   a ,  210   b  . . .  210   n  that communicate on the bus  208 . The operating system  212  includes an interrupt service routine (ISR) component  216  that handles interrupt requests received from the devices  210   a ,  210   b  . . .  210   n  transmitted across an interrupt line (not shown) of the bus  208  or transmitted using an interrupt message, such as a Message Signaled Interrupt (MSI). The operating system  212  further loads into memory  206  and executes one device driver  218   a ,  218   b  . . .  218   n  for each device  210   a ,  210   b  . . .  210   n  recognized by the operating system  212 . The device drivers  218   a ,  218   b  . . .  218   n  include device specific code to enable communication between the operating system  212  and the devices  210   a ,  210   b  . . .  210   n . The device drivers  218   a ,  218   b  . . .  218   n  each include an interrupt service routine (ISR)  220   a ,  220   b  . . .  220   n  component to handle interrupt requests from the associated device  210   a ,  210   b  . . .  210   n . The operating system ISR  216  utilizes a device driver list  222  that identifies all the loaded device drivers  218   a ,  218   b  . . .  218   n  registered with the operating system  212 . Further, as discussed, in Microsoft® Windows® operating systems, the operating system ISR  216  may assign a deferred procedure call (DPC)  224   a ,  224   b  . . .  224   n  to a device driver  218   a ,  218   b  . . .  218   n  to perform device related work. In non-Windows® operating systems, there is no DPC. 
   The device status registers  214   a ,  214   b  . . .  214   n  may each include the following information:
         Interrupt Cause/Status Registers (ICR)  230   a ,  230   b  . . .  230   n : provides interrupt status information, such as whether an interrupt is pending, a priority of a pending interrupt, etc.   ICR_Copy  232   a ,  232   b  . . .  232   n : a copy of the ICR  230   a ,  230   b  . . .  230   n  value used during operations.   IRQ_Required  234   a ,  234   b  . . .  234   n : flag indicates whether an interrupt request (IRQ) signal needs to be sent to the operating system  212  to notify the operating system  212  of a read/write request to be sent.       

     FIGS. 6 and 7  illustrates operations performed by device logic  236   a ,  236   b  . . .  236   n  implemented in each device  210   a ,  210   b  . . .  210   n  to signal the operating system  212  of interrupts in accordance with implementations of the invention. Control begins at block  300  with the device logic  236   a ,  236   b  . . .  236   n  checking ICR status registers  214   a ,  214   b  . . .  214   n . This checking operation at block  300  may be initiated at periodic intervals or in response to a change in one of the ICR  230   a ,  230   b  . . .  230   n  registers. If the ICR  230   a ,  230   b  . . .  230   n  value is equal to the ICR_Copy  232   a ,  232   b  . . .  232   n  value, then there has been no change to the interrupt status at the device and control proceeds back to block  300 . Otherwise, if there has been a change to the interrupt status as indicated by the difference between the ICR  230   a ,  230   b  . . .  230   n  value and ICR_Copy  232   a ,  232   b  . . .  232   n  value, then the ICR_Copy  232   a ,  232   b  . . .  232   n  is set (at block  304 ) to the value of the ICR  230   a ,  230   b  . . .  230   n  register. If (at block  306 ), the ICR_Copy  232   a ,  232   b  . . .  232   n  value is null, or some other value indicating that there is no pending interrupt at the device  210   a ,  210   b  . . .  210   n , then control proceeds back to block  300  to periodic interrupt checking. Otherwise, if (at block  306 ) the ICR_Copy  232   a ,  232   b  . . .  232   n  value indicates that an interrupt is pending, then the device logic  236   a ,  236   b  . . .  236   n  sends (at block  308 ) a message to the operating system  212  over the bus  208  to write the ICR_Copy  232   a ,  232   b  . . .  232   n  value to the ICR_Image  238   a ,  238   b  . . .  238   n  value in the computer memory  206 . As mentioned, an ICR_Image  238   a ,  238   b  . . .  238   n  and ICR_Image_Save  240   a ,  240   b  . . .  240   n  values are maintained in the computer memory  206  for each initialized device  210   a ,  210   b  . . .  210   n . The IRQ_Required flag  234   a ,  234   b  . . .  234   n  is then set (at block  310 ) to “true”, indicating that an interrupt needs to be sent to the operating system  212 . The result of the operations of  FIG. 6  is that the ICR  230   a ,  230   b  . . .  230   n  register value at the device  210   a ,  210   b  . . .  210   n  in the interrupt state is copied to the computer memory  206  for use by the device driver  218   a ,  218   b  . . .  218   n  when handling the device interrupt. This allows the device driver  218   a ,  218   b  . . .  218   n  to access the ICR status information from local memory  206  using a local memory bus (not shown) and avoid having to read the device status registers  214   a ,  214   b  . . .  214   n  over the bus  208 . In further implementations, the device may transmit information in addition to the described ICR register values to store in local memory  206  to relieve the device driver ISR from having to consume resources to read such additional information from the devices. 
   With respect to  FIG. 7 , control begins at block  320  with the device logic  236   a ,  236   b  . . .  236   n  periodically checking the IRQ_Required flag  234   a ,  234   b  . . .  234   n . If (at block  322 ) the IRQ_Required flag  234   a ,  234   b  . . .  234   n  is “true” and if (at block  324 ) the ICR  230   a ,  230   b  . . .  230   n  indicates that an interrupt is pending, then the device logic  236   a ,  236   b  . . .  236   n  sends (at block  326 ) an interrupt message, which may include additional information and status, to the operating system  212  over the bus  208  and sets (at block  328 ) the IRQ_Required flag  234   a ,  234   b  . . .  234   n  to “false”. 
   In certain implementations, the message sent at block  326  may comprise a Message Signaled Interrupt (MSI) as described in Section 6.8 of the “PCI Local Bus Specification”, Rev. 2.3, published by the PCI Special Interest Group (Mar. 29, 2002), which publication is incorporated herein by reference in its entirety. In MSI messaging, the device  210   a ,  210   b  . . .  210   n  sends a unique vector via a write transaction to a system address. The device  210   a ,  210   b  . . .  210   n  would encode the message with a unique address that the operating system  212  had assigned to the device  210   a ,  210   b  . . .  210   n  during initialization to enable the operating system  212  to distinguish which device  210   a ,  210   b  . . .  210   n  initiated the message. Alternative techniques known in the art for signaling the interrupt may be used. 
     FIG. 8  illustrates operations performed by the device driver ISR  220   a ,  220   b  . . .  220   n  in accordance with implementations of the invention. Control begins at block  350  with the device driver ISR  220   a ,  220   b  . . .  220   n  receiving a call from the operating system ISR  216  to handle an interrupt for the driver&#39;s device  210   a ,  210   b  . . .  210   n . In certain MSI implementations, the operating system  212  can determine the device driver  218   a ,  218   b  . . .  218   n  that initiated the interrupt because the operating system  212  associates a unique address with each device  210   a ,  210   b  . . .  210   n . In alternative implementations, such as those where an interrupt signal is generated on the bus  208  to a non-unique interrupt line, the operating system ISR  216  may poll each device driver  218   a ,  218   b  . . .  218   n  to determine the driver for the device  210   a ,  210   b  . . .  210   n  that initiated the interrupt. After being called to handle the interrupt, the device driver ISR  220   a ,  220   b  . . .  220   n  reads (at block  352 ) its ICR_Image  238   a ,  238   b  . . .  238   n  value from local memory  206 . If (at block  354 ) the driver&#39;s ICR_Image  238   a ,  238   b  . . .  238   n  value is null, or otherwise indicates that there is no pending interrupt for the device  10   a ,  10   b  . . .  10   n , then control ends because the called driver&#39;s device did not initiate the interrupt. Otherwise, if the ICR_Image  238   a ,  238   b  . . .  238   n  is not null, and indicates a pending interrupt, then the device driver ISR  220   a ,  220   b  . . .  220   n  sets (at block  356 ) the ICR_Image_Save  240   a ,  240   b  . . .  240   n  value to the read ICR_Image  238   a ,  238   b  . . .  238   n  value and sets (at block  358 ) the ICR_Image  238   a ,  238   b  . . .  238   n  value to NULL to indicate that there is no longer a pending interrupt that needs to be serviced. 
   The device driver ISR  220   a ,  220   b  . . .  220   n  then sends (at block  360 ) a message to the driver&#39;s device  210   a ,  210   b  . . .  210   n  over the bus  208  to acknowledge the current interrupt with the ICR_Image_Save  240   a ,  240   b  . . .  240   n  value and a message for the device  210   a ,  210   b  . . .  210   n  to disable certain of the device&#39;s interrupts, such as those indicated in the ICR  230   a ,  230   b  . . .  230   n  register. This acknowledgment message may include the ICR status read from the ICR_Image_Save  240   a ,  240   b  . . .  240   n  value in local memory  206 , which causes the device  210   a ,  210   b  . . .  210   n  to deassert the interrupt request line. The device driver ISR  220   a ,  220   b  . . .  220   n  then claims (at block  362 ) the interrupt and requests a DPC from the operating system ISR  216  to process the interrupt request and exits. 
     FIG. 9  illustrates operations the DPC  224   a ,  224   b  . . .  224   n  requested by the device driver ISR  220   a ,  220   b  . . .  220   n  performs to handle the interrupt. Upon initiating (at block  400 ) the process to invoke the DPC  224   a ,  224   b  . . .  224   n  to handle the interrupt, the DPC  224   a ,  224   b  . . .  224   n  performs (at block  402 ) device work related to the interrupt. For instance, if the device  210   a ,  210   b  . . .  210   n  comprises a network adaptor, such as an Ethernet adaptor, then the device related work performed by the DPC  224   a ,  224   b  . . .  224   n  may include processing receive and transmit buffers and performing link level error correction processing. After processing the interrupt, the device driver DPC  224   a ,  224   b  . . .  224   n  reads (at block  404 ) the ICR_Image  238   a ,  238   b  . . .  238   n  value in local memory  206  to determine whether the device  210   a ,  210   b  . . .  210   n  has initiated a subsequent interrupt, which would have been indicated by the device writing (at block  308  in  FIG. 6 ) a new ICR register value to the local memory copy of the ICR value in the ICR_Image  238   a ,  238   b  . . .  238   n  while the device driver ISR  220   a ,  220   b  . . .  220   n  or device driver DPC  224   a ,  224   b  . . .  224   n  is processing the current interrupt. If (at block  406 ) the ICR_Image  238   a ,  238   b  . . .  238   n  is null, or otherwise indicates that no new interrupt has been received, then the device driver DPC  224   a ,  224   b  . . .  224   n  enables (at block  408 ) the device  210   a ,  210   b  . . .  210   n  interrupts by writing the appropriate data over the bus  208  and then exits (at block  410 ) the DPC  224   a ,  224   b  . . .  224   n.    
   If (at block  406 ) the ICR_Image  238   a ,  238   b  . . .  238   n  value is not null, nor otherwise indicates that a new interrupt has been received, then the device driver ISR  220   a ,  220   b  . . .  220   n  sets (at block  412 ) the ICR_Image_Save  240   a ,  240   b  . . .  240   n  value to the ICR_Image  238   a ,  238   b  . . .  238   n  value and then sets (at block  414 ) the ICR_Image  238   a ,  238   b  . . .  238   n  value to NULL to indicate that the interrupt has been handled. The device driver ISR  220   a ,  220   b  . . .  220   n  then sends (at block  416 ) a message to the driver&#39;s device  210   a ,  210   b  . . .  210   n  over the bus  208  to acknowledge the current interrupt and to disable the device&#39;s interrupts in the manner described above with respect to block  360  in FIG.  8 . The described logic of  FIG. 9  has the device driver DPC  224   a ,  224   b  . . .  224   n  check whether a subsequent interrupt has arrived by the copy of the interrupt information from the local memory  206 . In this way, the device driver  224   a ,  224   b  . . .  224   n  avoids having to read the ICR register value from the device  210   a ,  210   b  . . .  210   n  over the bus  208 , which takes significantly longer. 
   The described implementations thus reduce the time for the device driver ISR  220   a ,  220   b  . . .  220   n  or DPC  224   a ,  224   b  . . .  224   n  to handle an interrupt by having the device driver ISR  220   a ,  220   b  . . .  220   n  or DPC  224   a ,  224   b  . . .  224   n  access ICR status and other information from local memory  206 , instead of having to read ICR status information over the bus  208  from the device status registers  214   a ,  214   b  . . .  214   n . This improved performance of the device driver ISR  220   a ,  220   b  . . .  220   n  or DPC  224   a ,  224   b  . . .  224   n  further improves the general CPU  204  processing performance by minimizing interrupt handling delays. 
   In certain implementations, the device driver  220   a ,  220   b  . . .  220   n  or DPC  224   a ,  224   b  . . .  224   n  when acknowledging the interrupt and disabling the device&#39;s interrupts, such as performed at block  360  in FIG.  8  and block  420  in  FIG. 9 , may issue two separate write transactions, one to write the ICR value to the ICR  230   a ,  230   b  . . .  230   n  register of the device  210   a ,  210   b  . . .  210   n  to cause the device to deassert the interrupt request line and issue a second write to the interrupt mask register to disable the device interrupts. 
     FIG. 10  illustrates an implementation of a device&#39;s  510  status registers  514  as including the ICR  530 , ICR_Copy  532 , and IRQ_Required  534   a ,  534   b  . . .  534   n  registers such as described above with respect to registers  230   a ,  230   b  . . .  230   n ,  232   a ,  232   b  . . .  232   n , and  234   a ,  234   b  . . .  234   n  in FIG.  5 . The status registers  514  of  FIG. 10  further includes a single acknowledgment and mask (AckAndMask) register  536  to indicate in a single register whether an interrupt was acknowledged and whether the interrupts are disabled. In certain implementations, such as at block  360  in FIG.  8  and block  420  in  FIG. 9 , the device driver ISR  220   a ,  220   b  . . .  220   n  or DPC  224   a ,  224   b  . . .  224   n  may issue a single write request to the AckAndMask register  536  to the ICR_Image_Save  240   a ,  240   b  . . .  240   n , which is the status value, to both acknowledge the interrupt and to disable the device&#39;s interrupts. By consolidating the acknowledgment and disable interrupts in a single write message, both CPU utilization  204  and bus  208  ( FIG. 4 ) bandwidth are conserved and optimized. 
   In implementations, where the device transmits an interrupt message using a shared interrupt line, the operating system must poll each device driver, such as described above with respect to  FIG. 3 , to determine the device driver of the device that initiated the request. 
     FIG. 11  illustrates logic implemented in the device driver ISRs  220   a ,  220   b  . . .  220   n  to claim an interrupt and request DPC resources to handle the interrupt processing in accordance with described implementations. The operations of  FIG. 11  may be initiated in response to a call from the operating system ISR  216  polling the device drivers  218   a ,  218   b  . . .  218   n  to determine the driver associated with the device  210   a ,  210   b  . . .  210   n  that initiated the request. Upon being invoked (at block  580 ), the device driver ISR  220   a ,  220   b  . . .  220   n  sets (at block  582 ) the request DPC  30  and the claim interrupt  32  flags ( FIG. 2 ) to “off”. The called device driver ISR  220   a ,  220   b  . . .  220   n  then reads (at block  584 ) the ICR_Image  238   a ,  238   b  . . .  238   n  value from local memory  206  to read the current ICR status information of the driver&#39;s device  20   a ,  20   b  . . .  20   n . If the read ICR_Image  238   a ,  238   b  . . .  238   n  indicates (at block  586 ) that the driver&#39;s device  210   a ,  210   b  . . .  210   n  submitted an interrupt request, then the called device driver ISR  220   a ,  220   b  . . .  220   n  writes (at block  588 ) the read ICR value from local memory to the device&#39;s AckAndMask register  536  over the bus  208  to disable and clear the interrupt indicator so that the device mask status register no longer indicates that an interrupt was sent. As discussed, writing to the AckAndMask register  536  both acknowledges the interrupt and disables the device&#39;s interrupts with a single write. The device driver ISR  220   a ,  220   b  . . .  220   n  then sets (at block  590 ) the request DPC flag  30  and claim interrupt flag  32  ( FIG. 2 ) to “on” and exits. The operating system ISR  216  upon detecting the value of these flags, would then stop polling the device drivers because the currently polled device driver  218   a ,  218   b  . . .  218   n  claimed the interrupt and would assign a DPC  224   a ,  224   b  . . .  224   n  resource to the acknowledging device driver  218   a ,  218   b  . . .  218   n  to handle the interrupt. In additional implementations, at block  590 , the device driver ISR  220   a ,  220   b  . . .  220  may implement the logic of  FIG. 4  to set the claim interrupt  32  flag ( FIG. 2 ) to “off” to allow the operating system ISR  216  to continue to poll device driver ISRs  220   a ,  220   b  . . .  220   n  in the manner discussed above with respect to  FIGS. 3 and 4  to improve interrupt handling performance. 
   Described implementations provide improved techniques for handling interrupts by having the device write interrupt status information to local memory where the information is available to the device driver. This allows the device driver to access the information locally and avoid having to read the data from the device&#39;s registers over a bus. 
   Additional Embodiment Details 
   The described techniques for handling device interrupts may be implemented as a method, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The term “article of manufacture” as used herein refers to code or logic implemented in hardware logic (e.g., an integrated circuit chip, Programmable Gate Array (PGA), Application Specific Integrated Circuit (ASIC), etc.) or a computer readable medium, such as magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, optical disks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, firmware, programmable logic, etc.). Code in the computer readable medium is accessed and executed by a processor. The code in which preferred embodiments are implemented may further be accessible through a transmission media or from a file server over a network. In such cases, the article of manufacture in which the code is implemented may comprise a transmission media, such as a network transmission line, wireless transmission media, signals propagating through space, radio waves, infrared signals, etc. Thus, the “article of manufacture” may comprise the medium in which the code is embodied. Additionally, the “article of manufacture” may comprise a combination of hardware and software components in which the code is embodied, processed, and executed. Of course, those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope of the present invention, and that the article of manufacture may comprise any information bearing medium known in the art. 
   In the described implementations, the bus interrupt handling implementations are included in a computer to handle interrupts from devices coupled to the bus enabling communication with the computer. In alternative implementations, the bus interrupt handling implementations may be implemented in any type of electronic device communicating with other devices, such as a hand held computer, a palm top computer, a laptop computer, a network switch or router, a telephony device, a network appliance, a wireless device, etc. 
   In the described embodiments, certain operations were described as being performed by the operating system ISR and device driver. In alterative embodiments, operations described as performed by the operating system ISR may be performed by the device driver ISR, and vice versa. 
   In the described implementations, the devices communicated an interrupt signal for an I/O request over an interrupt line of the bus. In alternative implementations, the devices may signal an interrupt in a different manner than through a bus interrupt signal. 
     FIGS. 1 ,  5 , and  10  illustrate certain information maintained in registers within the device and computer memory. In alternative implementations, additional or different types of information may be maintained. 
   The illustrated operations of  FIGS. 3 ,  4 ,  6 ,  7 ,  8 ,  9 , and  11  show certain events occurring in a certain order. In alternative embodiments, certain operations may be performed in a different order, modified or removed. Morever, steps may be added to the above described logic and still conform to the described embodiments. Further, operations described herein may occur sequentially or certain operations may be processed in parallel. Yet further, operations may be performed by a single processing unit or by distributed processing units. 
   The foregoing description of various embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.