Bug 16462 - Kernel does not correctly set IOAPIC interrupt types
Summary: Kernel does not correctly set IOAPIC interrupt types
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-08-17 17:59 UTC by John William
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-08-17 17:59:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description John William 2000-08-17 17:59:07 UTC
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 

Comment 1 Alan Cox 2000-08-22 17:03:26 UTC
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.

Comment 2 John William 2000-08-24 04:10:02 UTC
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?

Note You need to log in before you can comment on or make changes to this bug.