Method and apparatus for dynamic suppression of spurious interrupts

An apparatus and method for dynamic suppression of spurious interrupts in a computer system. More specifically, there is provided a method that comprises providing a look-up table comprising source IDs and corresponding time delays for each of a plurality of interrupt lines, monitoring each of the plurality of interrupt lines, and updating the time delays in the look-up table based on the monitoring of the interrupt lines, and a system for implementing the method.

BACKGROUND

A typical computer communicates with a great many input output (“I/O”) devices during its normal operation. One method of organizing and controlling this communication involves implementing interrupts. In an interrupt-based computer system, when one of the I/O devices requires attention from the computer's CPU, it generates an interrupt. When the CPU receives the interrupt, it typically stops its current task, sends an instruction to the I/O device to stop asserting the interrupt, and enters an interrupt mode to process the interrupt. Any interrupt generated by one of the I/O devices after the CPU has issued the instruction to de-assert the interrupt may be referred to as a “spurious interrupt”. After completing the interrupt-related processing tasks, the CPU re-arms the device, then typically exits from the interrupt mode and sends an End of Interrupt (“EOI”) signal to the interrupt controller. The EOI signal indicates that the CPU12has finished processing the interrupt and that the CPU is available to process another interrupt. If the CPU receives a spurious interrupt after this point, it may produce a “spurious interrupt error.”

In recent years, the number of spurious interrupts errors generated by typical computer systems has increased dramatically because increases in CPU speed have outpaced increases in I/O device speed and chipset speed. Since most of these spurious interrupt errors are a natural byproduct of unavoidable propagation delays within the computer system in combination with the previously mentioned widening gap in system component speeds, they are not a real cause for concern. Accordingly, there is often no need to generate an error. Conventional methods of suppressing spurious interrupts involve inserting a fixed delay before the processor generates the EOI signal. While this method can be effective in suppressing spurious interrupts, it can degrade system performance more than necessary by introducing often unnecessarily lengthy delays in interrupt processing.

DETAILED DESCRIPTION

Turning now to the drawings and referring initially toFIG. 1, a block diagram of an exemplary system for suppression of spurious interrupts in accordance with embodiments of the invention is illustrated and generally designated by the reference numeral10. The system10may include one or more processors or central processing units (“CPU”s)12. The CPU12may be used individually or in combination with other CPUs12. While the CPU12will be referred to primarily in the singular, it will be understood by those skilled in the art that a system with any number of physical or logical CPUs12may be implemented. Examples of suitable processors12include the Intel PENTIUM™ Processor family and the AMD ATHLON™ and OPTERON™ Processors. Each processor12may include a local interrupt controller18to handle interrupt requests that may be transmitted to the CPU12. The structure of the local interrupt controller will vary based on the design of the processor12. The CPU12may be operably coupled to one or more processor buses14.

A first chipset16may also be operably coupled to the processor bus14. The first chipset16is a communication pathway for signals between the processor and an input/output (I/O) bus26that is operably coupled to I/O devices28a–28d. Depending on the configuration of the system, any one of a number of different signals may be transmitted through the first chipset16. These signals include, but are not limited to, instructions from the processor12, data from the memory15, or interrupt requests from the I/O devices28a–28d. Those skilled in the art will appreciate that the routing of signals throughout the system10may vary without changing the underlying nature of the system.

The first chipset16may contain a memory controller17that may be operably coupled to memory15. Alternate embodiments, in which the memory15is operably coupled to the processor bus14or in which the memory controller17is operably coupled to the first chipset16, or in which the memory controller17is embodied in the processor12are also within the scope of the invention. The memory15may be any one of a number of industry standard memory types such as static random access memory (SRAM) devices or dynamic random access memory (DRAM) devices which may be arranged as single in-line memory modules (SIMMs) or dual in-line memory modules (DIMMs), for instance. As described below, the memory15may be used to store instructions or data to facilitate the suppression of spurious interrupts.

Further, as discussed above, the first chipset16may be operably coupled to one or more of the I/O devices28a–28dthrough to I/O bus26. The I/O devices28a–28dmay include, but are not limited to, displays, printers, and external storage devices. Each of the devices28a–28dis connected to an interrupt line24. There may be a dedicated interrupt line24for each of the devices28a–28dor one or more of the devices28a-28dmay share a single one of the interrupt lines24. The interrupt lines24may be operably coupled to a second chipset20. In alternate embodiments, the interrupt lines may be operably coupled to either the I/O bus26or the first chipset16.

Similar to the first chipset16, the second chipset20may also be a communication pathway for signals exchanged between the processor12and a second input/output (“I/O”) bus30that is operably coupled to additional I/O devices32a–32b. The second chipset20may also be operably coupled to the processor bus14to facilitate communication with each of the processors12. Depending on the configuration of the system, any one of a number of different signals may be transmitted through the second chipset20. These signals may include, but are not limited to, instructions from the processor12, interrupt requests from I/O devices32a–32b, or data from the memory15, for instance.

The second chipset20may also include an interrupt controller22. Typically the interrupt controller22is any one of a number of industry standard Programmable Interrupt Controllers (“PICs”) or Advanced Programmable Interrupt Controllers (“APICs”). The interrupt controller22and the local interrupt controller18a-18dmay work separately or in conjunction in the processing of system interrupts. It will be understood by those skilled in the art thatFIG. 1merely illustrates one possible block diagram illustrating an exemplary system for suppression of spurious interrupts in accordance with embodiments of the invention, as described further below. Alternate embodiments, in which the components illustrated inFIG. 1may be altered, combined, or deleted, are within the scope of the invention. For example, in alternate embodiments, the number of chipsets16,20may vary or the interrupt lines24may be embedded within one of the I/O buses26,30.

The CPU12communicates with many of the I/O devices28a–28d,32a–32bduring normal operation. One method of organizing and controlling this communication involves implementing interrupts. In an interrupt-based computer system, when an I/O device28a–28d,32a–32brequires attention from the CPU12, it generates an interrupt. The interrupt typically includes both the request for attention and a request for a specific processing task for the CPU12to perform. An I/O device28a–28d,32a–32btypically generates the interrupt by transmitting a signal through the interrupt line24to the interrupt controller22. The interrupt controller22then transmits a signal containing the interrupt to the CPU12. When the CPU12receives the signal from the interrupt controller22, it typically stops its current task, sends an instruction to the I/O device28a–28d,32a–32bto stop asserting the interrupt, and enters an interrupt mode to process the interrupt. After completing the interrupt-related processing tasks, the CPU12typically exits from the interrupt mode and sends an End of Interrupt (“EOI”) signal to the interrupt controller22. The EOI signal indicates to the interrupt controller22that the CPU12has finished processing the interrupt and that the CPU12is now available to process another interrupt. The EOI signal is generally implemented because the typical interrupt controller22will not transmit a next-in-time interrupt to the CPU12until it receives an EOI signal.

Any interrupt generated by one of the I/O devices28a–28d,32a–32bafter the CPU12has issued an instruction to de-assert the interrupt may be referred to as a “spurious interrupt.” A “spurious interrupt error” may be produced if the CPU12enters the interrupt mode to process a spurious interrupt. A warning message to the operator may accompany the spurious interrupt error. The risk of spurious interrupt errors is greatest when the CPU sends the EOI signal near in time to when it instructs an I/O device28a–28d,32a–32bto stop asserting the interrupt. In this case, the interrupt controller22will be instructed to start accepting new interrupts at approximately the same time that the I/O device28a–28d,32a–32bstops asserting its interrupt. Ideally, this would not cause a problem. However, as discussed further below, an I/O device28a–28d,32a–32bis unable to instantly ‘turn off’ the interrupt signal because of unavoidable propagation delays, and the interrupt line24continues to contain a residual interrupt signal for a period of time after an I/O device28a–28d,32a–32bhas stopped asserting the interrupt. Since in this case the interrupt controller22has already received the EOI signal from the CPU12, the interrupt controller22is open to receive new interrupts and can misinterpret the residual interrupt signal as a new interrupt. If this happens, the interrupt controller22will transmit the interrupt signal to the CPU12, and the CPU12will stop its current task and re-enter an interrupt mode to process the spurious interrupt. As discussed above, this may result in a spurious interrupt error.

As discussed above, spurious interrupts are primarily caused by unavoidable propagation delays within the system. The unavoidable propagation delays within the system include, but are not limited to, the time required for the signal containing the CPU's instruction to reach an I/O device28a–28d,32a–32b, the time required for the I/O device28a–28d,32a–32bto respond to the instruction and de-assert the interrupt, and the time required for the residual interrupt signal to be purged from the system10. Each one of the unavoidable propagation delays has a cumulative effect on total unavoidable propagation delay within the system10. Thus, while the corrective actions for spurious interrupts discussed below typically compensate for the residual interrupt signal, it should be appreciated that in doing so, the corrective actions are actually compensating for the cumulative propagation delay. This is the case because the residual interrupt signal is the final unavoidable propagation delay in a series of unavoidable propagation delays within the system10and thus manifests the cumulative propagation delay.

As previously discussed, the number of spurious interrupt errors in a typical computer system has increased dramatically because increases in CPU speed have dramatically outpaced increases in I/O device speed and chipset speed. Most of these spurious interrupt errors are a natural by-product of the unavoidable propagation delays discussed above in combination with this widening gap in the speed of the system components. For this reason, most spurious interrupt errors are not a cause for concern, and there is no need to generate an error. It should be noted, however, that propagation delays that exceed a certain system-specific upper allowable time limit may be an indication of a more serious problem. Further, it may not be desirable to suppress spurious interrupts that indicate an underlying system problem outside of cumulative propagation delay.

Since the majority of spurious interrupt errors are not indicative of any real problem with the system10, one conventional method of dealing with spurious interrupt errors is merely to ignore them. While simple to execute, this method has several prominent disadvantages. First, it produces tens, hundreds, or even thousands of warning messages to the user that are not indicative of any real problem with the system. This flood of warnings may cause the user to overlook warning messages that are indicative of an actual problem that should be addressed. Further, thousands of potentially insignificant warning messages can create user dissatisfaction and increased support costs to address the customer dissatisfaction. Finally, excessive processing of spurious interrupts may impinge system performance in two dimensions: first, the processor must dispatch spurious interrupts which reduces compute cycles used for legitimate work; second, the I/O subsystem may be throttled because the processor spends more time than necessary in interrupt processing for spurious interrupts, thus neglecting other I/O devices.

Another conventional method of handling spurious interrupt errors is for the CPU12to delay transmitting the EOI signal to the interrupt controller22for a fixed period of time to compensate for the propagation delay. While this methodology can be very effective in reducing spurious interrupt errors, it can degrade overall system performance by over compensating for propagation delay because the unavoidable propagation delay is not the same for each of the I/O devices28a–28d,32a–32bconnected to the system10. For example, to avoid 95% of spurious interrupt errors, the fixed EOI signal delay must be set longer than 95% of the propagation delays. This creates an obvious inefficiency because in the vast majority of cases, the fixed EOI signal delay will be longer than necessary to avoid the spurious interrupt error. This excess delay is time that the processor12could be using to perform other tasks.

Unlike the systems described above which either ignore the spurious interrupt problem or insert a fixed delay into the interrupt service routines, this presently disclosed system10can determine a corrective action dynamically on a per interrupt basis. The possible corrective actions include, but are not limited to, implementing a delay, generating a warning message for the operator, logging the event, masking the offending interrupt, or deactivating the affected device. Embodiments of the present invention can dynamically adjust the corrective action based on a variety of factors, including changes to the system configuration, system activity level, processor speeds or throttling, or differences/variations in signal timing across chipset lots or computer models.

Further, unlike previous systems, the present techniques may also employ a look-up table19(hereafter referred to as an “interrupt profile table”) that permits the system10to maintain a separate delay value for each interrupt. The interrupt profile table19allows the system10to “fine-tune” the optimal delay for each interrupt line24without arbitrarily penalizing other functions of the I/O devices28a–28d,32a–32bassigned to different interrupts or other I/O devices that depend on the same software device driver. By profiling the interrupts and calibrating a delay specific to each interrupt line24, this invention improves system performance, processing speed, and customer satisfaction with the system10. In addition, the interrupt profile table19may also comprise other corrective actions in addition to or in place of a time delay.

Referring now toFIG. 2, a flow chart illustrating an exemplary process for interrupt management in accordance with exemplary embodiments of the present invention is depicted and generally designated by the reference numeral40. In one embodiment, the system10employs the process40in dispatching interrupts from the I/O devices28a–28d,32a–32b. The process40begins when the CPU12receives an interrupt as indicated in block42. After the interrupt is received, the system10begins the process of answering the interrupt as illustrated in block44. This process is also known as “interrupt dispatching.” During the interrupt dispatching process, the CPU12transmits an instruction to the I/O device28a–28d,32a–32bthat asserted the interrupt instructing that I/O device28a–28d,32a–32bto stop asserting the interrupt. Next, the system10may invoke an Interrupt Service Routine (“ISR”) that corresponds to the I/O device28a–28d,32a–32bthat generated the interrupt as illustrated in block46. If the system10is unable to find an ISR that corresponds to the I/O device28a–28d,32a–32bthat requested the interrupt, the system10may generate a warning message (not shown).

After invoking the device driver ISR (block46), the system10determines whether or not any one of the I/O devices28a–28d,32a–32bclaims the ISR as illustrated in block48. If the ISR is claimed, the system may implement a corrective action as indicated in block52. If the ISR is not claimed by one of the I/O devices28a–28d,32a–32b, the system will determine whether or not there are other ISRs that may be associated with the particular interrupt being asserted as shown in block50. Typically there will be other ISRs associated with the particular interrupt if two or more I/O devices28a–28d,32a–32bare sharing a single interrupt line24. Since in this situation, the system10cannot determine which of the I/O devices asserted the interrupt, the system will invoke each of the multiple ISRs associated with the particular interrupt to ensure that the interrupt request did not come from any of the I/O devices28a–28d,32a–32bsharing the interrupt line24. Interrupt line sharing can occur with any I/O device but is especially typical in PCI I/O devices. If the system10has invoked all of the ISRs associated with a particular interrupt and none of them have been claimed by one of the I/O devices28a–28d,32a–32b, the system flags the interrupt as spurious.

Next, the system10may implement a corrective action as illustrated by block52. In prior systems, this corrective action typically only involved adding a fixed delay. Corrective actions in accordance with the present techniques will be described further below with reference toFIG. 3. After the corrective action is complete, the system10deems the interrupt to be complete (block54), and sends the End of Interrupt (“EOI”) signal to the interrupt controller22as illustrated by block55.

At this point, the interrupt controller22will once again begin transmitting interrupts to the CPU12. As discussed above, it is at this point where the spurious interrupt problem is most likely to manifest itself. If the first time that the system10executed process40, the corrective action (block52) was either not performed (i.e. spurious interrupts are being ignored), or it was not sufficient to compensate for the unavoidable propagation delays, the system10will interpret the residual interrupt signal as a new interrupt and will once again execute the process40. Since the residual interrupt signal is not indicative of any actual new interrupt request from one of the I/O devices28a–28d,32a–32b, none of the ISRs (block48) will claim the interrupt. The residual interrupt signal will then be deemed a spurious interrupt as indicated by block50, and a spurious interrupt error will be generated. Advantageously, the present system10addresses this problem by dynamically adjusting the corrective action (typically a time delay) such that in all but a certain percentage of cases, the system will not transmit the EOI signal (block55) until after the residual interrupt signal has been purged from the interrupt line24.

As discussed above, in one exemplary embodiment, the system10may employ an interrupt profile table19to permit the system10to individually adjust the corrective action for each interrupt line24. The interrupt profile table19may be a static table based on the total number of interrupt lines24, or it may be dynamically created as each interrupt line is asserted by one of the I/O devices28a–28d,32a–32b. In one embodiment, where there are up to 224 possible interrupt lines, the interrupt profile table19will contain 224 records. In this embodiment, the interrupt profile table19is automatically created by the software that handles interrupt registration during system boot-up. The interrupt profile table19may include a time delay and a “threshold scorecard value” for each of the interrupt lines24as described further below. The interrupt profile table19may also include an upper allowable limit, an upper threshold value, and a lower threshold value for each of the interrupt lines24as described further below. In alternate embodiments, the upper allowable limit, the upper threshold value, or the lower threshold value may be the same for each of the interrupt lines24. In this embodiment, the upper allowable limit, the upper threshold value, or the lower threshold value may not be stored in the interrupt profile table19. Lastly, as discussed above, the interrupt profile table19may also contain other corrective actions that the system10may employ in addition to or in place of a time delay.

The upper allowable limit for each time delay is the maximum delay that the system10may dynamically set for a particular interrupt. Once the system10reaches the upper allowable limit, it will stop dynamically increasing the time delay for a given interrupt line24even if further increases could reduce the number of spurious interrupt errors. The upper allowable limit may be set by the system operator, and may be the same for all interrupts or may be set individually per interrupt. The upper allowable limit is important because excessive propagation delays can be indicative of a serious problem with the affected I/O device28a–28d,32a–32b. Without an upper allowable limit, serious errors or data loss can occur if the CPU12delays too long before resuming the acceptance of interrupts from the interrupt controller22.

As stated above, the interrupt profile table19may also contain the upper threshold value and the lower threshold value for each of the interrupt lines24. The upper threshold value is the highest percentage of spurious interrupt errors that the system10will allow for a particular interrupt before the system increases the time delay to reduce the number of spurious interrupt errors. The system10will not, however, increase the delay time more than one fixed increment above the upper allowable limit. Similarly, the lower threshold value is the lowest percentage of spurious interrupt errors that the system10will allow for a particular interrupt line24before the system decreases the delay time in order to improve system performance. The system10cannot reduce the delay time below zero.

While the system10is running, it maintains a running tally of the current ratio of spurious interrupt errors to total interrupts processed called the threshold scorecard value. The threshold scorecard value is computed over a predetermined number of past interrupts (e.g., it may be computed over the last 256 processed interrupts, the last 1056 processed interrupts, etc.). If the threshold scorecard value is computed over the past 256 interrupts, the threshold scorecard value will be equal to the percentage of the last 256 interrupts for a particular interrupt line24that were spurious interrupt errors. The system10may use the threshold scorecard value to determine if and when the percentage of spurious interrupt errors for a particular interrupt line has exceeded the upper threshold value or has fallen below the lower threshold value.

The upper threshold value may be advantageously implemented because it is often inefficient to eliminate all of the spurious interrupt errors on a given interrupt line24. To illustrate the point, if a 250 ns delay would be sufficient to compensate for 98% of the spurious interrupt errors for a particular interrupt line24and a 1 μs delay would be sufficient to compensate for 100% of spurious interrupt errors, even though the 100% solution will eliminate all of the spurious interrupt errors, it may be inefficient because 98% of the time, the system is delaying 750 ns more than required to compensate for the residual interrupt signal.

Similarly, the lower threshold value may be implemented because it may not be efficient to continue to implement a particular time delay simply because the threshold scorecard value is below the upper threshold value. For example, if a time delay anywhere in the range from 100 ns to 250 ns will produce the same number of spurious interrupt errors and generate a threshold scorecard value of 1%, and the lower threshold value is set at 2%, the system10could reduce the time delay from 250 ns to 100 ns without increasing the number of spurious interrupts errors. This decrease would increase the system speed without generating any additional spurious interrupt errors. As long as the threshold scorecard value is below the lower threshold value, the system10may continue to reduce the delay time until the delay time becomes zero. In this way, the system10is generally able to dynamically adjust the delay time to keep the threshold scorecard value between the upper and lower threshold values.

The upper and lower threshold values may be entered by an operator and are typically determined by balancing system efficiency with the elimination of spurious interrupt errors. In one exemplary embodiment, the upper and lower threshold values may be in the 1%–5% range, but either value can be configured higher or lower depending on the needs of the operator. The system may be configured to allow the operator to enter a unique upper and lower threshold value for each interrupt line24or may use the same upper and lower threshold values for all of the interrupt lines.

When the system10is first activated the time delay for each interrupt line24may be set to zero. As the system10runs, it will dynamically adjust the value of each time delay as discussed above and further described below with reference toFIG. 3. The upper allowable limit, the lower threshold value, and the upper threshold value are entered by the operator and are not dynamically adjusted as the system runs. If the time delay for a given interrupt line24remains at zero, then there have been very few, if any, spurious interrupt errors in recent history. Additionally, it is important to note that it is not uncommon for there to be a few stray spurious interrupt errors during device initialization and then no spurious interrupt errors for the interrupt line24after initialization. In this case, if the number of spurious interrupt errors during initialization never causes the threshold scorecard value to exceed the upper threshold limit, the time delay will remain at zero. (i.e. no short-term penalty). However, even if the number of spurious interrupt errors during initialization does briefly cause the threshold scorecard value to exceed the upper threshold limit, the time delay that is instituted will erode back to zero if no other spurious interrupts are processed (i.e. there is a short-term penalty, but no long-term penalty).

In one embodiment, one of the I/O devices28a–28d,32a–32bin the system10may be configured as a permanent or persistent storage device. In this embodiment, the interrupt profile table19may be stored on the permanent or persistent storage device and loaded when the system10is restarted. Among other advantages, this embodiment allows the system to skip the ‘training period’ that occurs if the time delay for each interrupt line24is initially set to zero after a reboot. In this embodiment, the system10will initially generate fewer spurious interrupt errors after a reboot than in an embodiment where the system10has to adjust each time delay from zero. In another embodiment, the system10may be configured to permit the operator to manually adjust the initial delay for a specific interrupt line or a specific I/O device28a–28d,32a–32b. This feature is particularly useful if a particular one of the interrupt lines24or the I/O devices28a–28d,32a–32bhas a known problem, because the system10can be preset to compensate for the known problem.

Turning now toFIG. 3, a flow chart illustrating an exemplary process for implementing corrective action in a spurious interrupt suppression scheme in accordance with embodiments of the invention is depicted and generally designated by the reference numeral80. In one embodiment, the process80is executed by a modified interrupt driver in a host operating system's software kernel. Additional embodiments, which may be implemented through hardware or software, are within the scope of the invention. Initially, the system10determines whether or not the interrupt being processed is a spurious interrupt. If the interrupt being processed is a spurious interrupt, the system10will follow process80. If the interrupt being processed is not spurious, the system10will follow process105, which is described below in connection withFIG. 4. The system typically determines whether the interrupt is a spurious interrupt based on entry parameters (a spurious interrupt flag, for example) or by using the interrupt source ID parameter. However, other methods of identifying spurious interrupts may also be implemented.

If the interrupt is determined to be spurious, the system10updates the threshold scorecard value to reflect that the interrupt was spurious as indicated in block86. Next, the system10reads the delay enable flag for the interrupt from the interrupt profile table19as indicated in block88. In one embodiment, there is a unique delay enable flag and delay time associated with each interrupt in the interrupt profile table19. Next, the system10determines whether the delay time read from the interrupt profile table19is enabled and should be used (block90). If the delay is not enabled, the system will generate a spurious interrupt error warning message and issue the EOI signal as illustrated in blocks103and104. If the delay is enabled, the system10determines if the threshold scorecard value exceeds the upper threshold value as indicated in block92. If the threshold scorecard value does not exceed the upper threshold value, the system implements the time delay from the interrupt profile table19as indicated by block102. If the threshold scorecard value does exceed the upper threshold value the system will determine whether the delay time from the interrupt profile table19has exceeded the upper allowable limit (block94). If the upper allowable limit has been exceeded, the system10will generate an upper allowable limit error to notify the operator that the delay time has reached the upper allowable limit and cannot be further increased as indicated in block96. If the upper allowable limit has not been exceeded, the system will increase the delay time for the interrupt and record the increased delay time to the interrupt profile table19as illustrated in blocks98and100. In either case, the system10will implement the delay time from the interrupt profile table19as indicated by block102. It should be noted, that if the system10increased the delay time (block98), the system will implement this increased delay time. Lastly, the system10will generate a spurious interrupt message and issue the EOI signal as illustrated in blocks103and104.

Turning now toFIG. 4, a flow chart illustrating an exemplary process for implementing corrective action in a spurious interrupt suppression scheme in accordance with embodiments of the invention is depicted and generally designated by the reference numeral106. In one embodiment, the process106is executed by a modified interrupt driver in a host operating system's software kernel. Additional embodiments, which may be implemented through hardware or software, are within the scope of the invention.

The system10will follow process105if the interrupt is determined to not be spurious. First, the system10will update the threshold scorecard value for the interrupt in the interrupt profile table19as indicated in block105. Next, the system10will read the delay enable flag associated with the interrupt from the interrupt profile table19as indicated in block108. The system10will then determine whether or not the delay time from the interrupt profile table19is enabled and should be used as indicated in block110. If the delay is not enabled, the system will issue the EOI signal as indicated in block120. If the delay is enabled, the system10will determine if the threshold scorecard value is below the lower threshold value as illustrated by block112. If the threshold scorecard value is above the lower threshold value, the system10will implement the delay from the interrupt profile table19as indicated in block118. If the threshold scorecard value is below the lower threshold value, the system10will decrease the delay time associated with the interrupt and save the decreased delay time to the interrupt profile table19, as indicated in blocks114and116. Next, the system10will implement the delay associated with the interrupt from the interrupt profile table19(block118). It should be noted, that if the delay time was decreased, the system10will implement the decreased delay time. Lastly, the system will issue the end of interrupt signal to the interrupt controller (block120). As described above, transmitting the EOI signal will enable the interrupt controller to transmit new interrupts to the CPU12.

It should be noted that with minor modifications readily apparent to those skilled in the art, the system10can also be used to assist in debugging device drivers that are suspected of creating excessive spurious interrupt errors.

The base functions described above with reference toFIGS. 2 and 3may comprise an ordered listing of executable instructions for implementing logical functions. The ordered listing can be embodied in any computer-readable medium for use by or in connection with a computer-based system that can retrieve the instructions and execute them. In the context of this application, the computer-readable medium can be any means that can contain, store, communicate, propagate, transmit or transport the instructions. The computer readable medium can be an electronic, a magnetic, an optical, an electromagnetic, or an infrared system, apparatus, or device. An illustrative, but non-exhaustive list of computer-readable mediums can include an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (magnetic), a read-only memory (ROM) (magnetic), an erasable programmable read-only memory (EPROM or Flash memory) (magnetic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical).