Institut für Informatik Lehrstuhl 7 up
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:
Time Differences
Normally you would expect the differences to always be more or less exactly one second (109 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:
IRQ 7 Index 2 to 4
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:
Ulrich Windl, the author of the NTP FAQ and the Linux PPS API implementation, mentioned a similar problem reported by Poul-Henning Kamp. He noticed that SMM interrupts disturbed his measurements.

The effects described above did not show up using a 2.4.18 kernel.
Another solution is to configure the BIOS of our nodes to use I/O 0x278 and IRQ 5 for the parallel port and load the parallel port PPS driver with appropriate parameters.

Dipl.-Inf. Kai-Steffen Hielscher