Red Hat Bugzilla – Bug 16462
Kernel does not correctly set IOAPIC interrupt types
Last modified: 2008-05-01 11:37:57 EDT
I have an old HP Vectra XU5/90 SMP (dual Pentium 100) system and found a
bug in the interrupt setup code in the kernel (2.2.16).
The problem is that the kernel does not always set the interrupt type
correctly. In my case, the SCSI controller and one of my ethernet cards
share an IRQ. This cannot be changed, because the on-board SCSI controller
and both PCI slots (yes, this is an old machine) share the same physical
interrupt line. The kernel insists on configuring the interrupt as type IO-
APIC-EDGE and not IO-APIC-LEVEL (shared interrupts must be of type LEVEL).
Depending on the activity on the shared devices the problems can range
from lockups on boot to the device ceasing to respond to a system hang.
Booting with the "noapic" option "solves" the problem by making all
interrupts of type XT-PIC routed to CPU0. This is a less than optimial
solution but at least allows the system to boot.
The problem could be caused by bad BIOS information as to the type of
interrupt, but shouldn't the kernel recognize that a shared PCI interrupt
must be of type LEVEL and not EDGE?
Another alternative would be to allow a boot option to force interrupt
We depend on the bios tables. If they are wrong we cant do a lot about it. You
can override bits of the apic configuration but if the bios is wrong I think
noapic is way safer
As to the other comment. Some combinations of edge trigger devices can be used
together. Not many but enough I'd be reluctant to second guess vendor info that
on most boards is *very* good data.
Well something should be done to fix this. Otherwise, every HP Vectra XU 5/90
SMP in existence won't boot the standard RedHat distro if something is
installed in one of the PCI slots. I can tell you the "solution" (noapic) isn't
immediately obvious either. Getting the out-of-the box RH6.2 running on one of
these machines is difficult enough because of the AM53C974 SCSI controller but
the "noapic" thing can really throw someone for a loop.
I hate to bring up the comparison, but there must be a solution because NT 4.0
dual-boots fine on the same machine with the same hardware that causes RH6.2 to
Maybe another way to look at the problem might be: are there any consequences
to forcing LEVEL on a PCI interrupt? Particularly a shared one?
Or is the performance hit of "noapic" not enough to worry about so I should let
the whole thing go?