#1706 closed defect

pc386: spurious interrupt 7

Reported by: Ralf Corsepius Owned by: Joel Sherrill
Priority: normal Milestone: 4.11
Component: bsps Version: 4.10
Severity: normal Keywords:
Cc: strauman@…, sebastian.huber@… Blocked By:
Blocking:

Description (last modified by Gedare Bloom)

When running the testsuites real (PC-)HW, using either pc386 or pc686 BSP, I am facing long series of "spurious interrupt 7" messages, e.g. with ticker.exe.

No idea why and no idea what to do about them.

Checking /proc/interupts on this machine under linux tells:

# cat /proc/interrupts

CPU0 CPU1

0: 31084 0 IO-APIC-edge timer
1: 29 0 IO-APIC-edge i8042
7: 116 0 IO-APIC-edge
8: 32 0 IO-APIC-edge rtc0
9: 21 0 IO-APIC-fasteoi acpi

12: 137 0 IO-APIC-edge i8042
16: 12 0 IO-APIC-fasteoi uhci_hcd:usb5, i915
17: 0 0 IO-APIC-fasteoi ra0
18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
19: 0 0 IO-APIC-fasteoi uhci_hcd:usb3
23: 435 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
40: 0 0 PCI-MSI-edge pciehp
41: 0 0 PCI-MSI-edge pciehp
42: 12189 0 PCI-MSI-edge ahci
43: 852 0 PCI-MSI-edge eth0
44: 499 0 PCI-MSI-edge hda_intel

NMI: 0 0 Non-maskable interrupts
LOC: 37673 50198 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
PND: 0 0 Performance pending work
RES: 1015 1571 Rescheduling interrupts
CAL: 95 137 Function call interrupts
TLB: 235 204 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 1 1 Machine check polls
ERR: 117
MIS: 0

If I understand this correctly, IRQ7 is unassigned by the BIOS.

Change History (5)

comment:1 Changed on 10/01/10 at 09:14:57 by Ralf Corsepius

Milestone: 4.114.10

comment:2 Changed on 10/01/10 at 09:56:01 by Sebastian Huber

Cc: Sebastian Huber added

comment:3 Changed on 05/31/12 at 02:27:44 by strauman

Cc: strauman added

comment:4 Changed on 05/31/12 at 14:23:19 by Ralf Corsepius

Replying to comment:13:

I have the parallel port

The machine this issues had started with doesn't have a parallel port ;)

Replying to comment:14:

I think it is really spurious

If you define "spurious" as "unexpected", then you're right, RTEMS doesn't expect them and reports them as "spurious".

where people have had this
with various Linux kernel configurations.

Well, I am not having any problems with irq7 with Linux on this particular machine.

FWIW: After ca. 36 hours of uptime under Fedora 17 on this machine from today:
# cat /proc/interrupts

CPU0 CPU1

...
7: 26 0 IO-APIC-edge
...

This is very different than RTEMS behaviour, where these "spurious irq 7" seem to appear at very high rate and in much larger numbers.

What makes me think is this link: http://www.daemon-systems.org/man/isa.4.html

comment:5 Changed on 11/22/14 at 13:50:10 by Gedare Bloom

Description: modified (diff)
Milestone: 4.104.11
Resolution: wontfix
Status: newclosed
Version: HEAD4.10
Note: See TracTickets for help on using tickets.