Kai-Steffen Hielscher 28/03/02

Spurious 8259A interrupt: IRQ 7

During the development of our PPS API driver for the parallel port we measured the time difference between two successive invocations of interrupt 7, because the GPS receiver was delivering PPS pulses to pin 10 of the parallel port and the control port was programmed to generate an interrupt upon receiving a rising edge of a signal on this pin. The results we got using kernel 2.4.16-NANO are shown in the following graph:

Normally you would expect the differences to always be more or less exactly one second (10⁹ ns). Something must have disturbed the PPS signal. We looked at our source code but could not find any errors that could produce such results. We looked at the parallel port with a logic analyzer and found no signals besides our PPS pulses. Some other task running on the system could have been the source for those errors. When we looked at the log file of the system we found entries stating Spurious 8259A interrupt: IRQ 7. A spurious interrupt is an IRQ that happens, but no interrupt handler is registered for this IRQ. To investigate further, we configured the parallel port to use IRQ 5 and I/O-port 0x278 in the BIOS of our systems. When left unchanged, the Plug-and-Play BIOS used IRQ 7 for the USB controller now. We then marked IRQ 7 as used by ISA and wrote an interrupt handler to generate time stamps for every invocation of IRQ 7. Even when no parallel port is connected to IRQ 7, those spurious interrupts occurred. The measurements of the time differences of the PPS pulses using IRQ 5 were completely normal now with all deltas distributed around one second. A graph for the invocation times of the IRQ 7 handler is shown below:

Plotting only the times for the second to the fourth invocation of our interrupt handler, which appear as a horizontal line in the graph shown above gives the following picture:

As you can see, there is a time difference of exactly 10ms between each invocation of the interrupt handler.
 
Searching the Linux Kernel mailing list archive we found the following explanations for spurious interrupts:

• Floating status bits on the parallel port
• not applicable for our case: No parallel port associated with the IRQ 7.
• Problems with I/O-APIC code in the kernel
• not  applicable for our case: Even when using a kernel without I/O-APIC support compiled in, our IRQ 7 handler was called.
• Some other signal lines floating
• not  applicable for our case: Pattern too regular.
• Problems with tulip chip set
• not  applicable for our case: No tulip based network adapter card used.
• Problems with a binary nVidia driver
• not  applicable for our case: No binary nVidia driver used.
• Some errors in the initialization of the chip set (VIA VT8363A/82C686B on an Asus A7V133 main board)
• could be the case here: IRQ 7 handler is less frequently called with a new BIOS firmware. We will check if the interrupt handler for IRQ 7 is also called using a DOS start disk to determine if this is a linux specific problem.
• A device issues interrupt requests for a period of time too short to be recognized correctly by the 8259A, or the CPU acknowledges ( /INTA) the request too late (See data sheet for the Intersil 82C59A , page 6)
• could be the case here, to investigate further we'll have to remove all PCI cards from our system and see if the interrupts continue to appear.