Bug 137459 - Interrupt problems on Supermicro P4SCT+II motherboard
Summary: Interrupt problems on Supermicro P4SCT+II motherboard
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-28 16:44 UTC by Robert Clark
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-11-17 20:27:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
dmesg info (10.02 KB, text/plain)
2004-10-28 16:46 UTC, Robert Clark
no flags Details
lspci info (8.02 KB, text/plain)
2004-10-28 16:48 UTC, Robert Clark
no flags Details
dmesg info for nahant (11.12 KB, text/plain)
2004-11-01 15:56 UTC, Robert Clark
no flags Details

Description Robert Clark 2004-10-28 16:44:20 UTC
Intel PRO/100S & Intel PRO/1000MT PCI-X Ethernet cards are unusable
with the P4SCT+II motherboard. Some of the ports are being assigned
interrupt 267:

PCI->APIC IRQ transform: (B3,I4,P0) -> 267
PCI->APIC IRQ transform: (B4,I4,P0) -> 267
PCI->APIC IRQ transform: (B4,I4,P1) -> 267

and cannot be configured with ifconfig (SIOCSIFFLAGS).

Others can be configured but receive no interrupts (based on the
numbers in /proc/interrupts) and see no traffic.

In all cases, link status is reported correctly by mii-tool.

This is with kernel-2.4.21-20ELsmp, the latest BIOS (1.1). The cards are:

Intel PRO/1000MT 4-port Ethernet card (PCI-ID 8086:101D Rev 1)
Intel PRO/100S   2-port Ethernet card (PCI-ID 8086:1229 Rev D)

Comment 1 Robert Clark 2004-10-28 16:46:26 UTC
Created attachment 105900 [details]
dmesg info

Attaching some information from dmesg

Comment 2 Robert Clark 2004-10-28 16:48:18 UTC
Created attachment 105901 [details]
lspci info

Attaching output from lspci -v

Comment 3 Robert Clark 2004-10-30 13:21:03 UTC
Tested the same setup with Nahant and it does work - the kernel
assigns a completely different set of interrupts.

Also tested with vanilla 2.4.27 which exhibits the same problem as
2.4.21-20ELsmp, so it looks like it's a 2.4/2.6 thing.

Comment 4 John W. Linville 2004-11-01 14:36:15 UTC
Please try adding "noapic" and/or "acpi=off" to the kernel command
line.  Does that make things "work"?  Do the interrupts assigned in
that case match the ones assigned under Nahant?

Comment 5 Robert Clark 2004-11-01 15:56:15 UTC
Created attachment 106020 [details]
dmesg info for nahant

Attaching some information from dmesg under Nahant.

I'm pretty sure I tested both noapic and acpi=off before trying Nahant, but
I'll reinstall RHEL3 and make sure.

Comment 6 Robert Clark 2004-11-02 17:43:41 UTC
With noapic, I'm able to run ifconfig on the troublesome ports but
they still receive no interrupts and see no traffic.

acpi=off doesn't seem to have any affect.

I've had some feedback from the LKML suggesting that CONFIG_ACPI=y was
needed to fix this, so I tried compiling vanilla 2.4.27 with the same
.config as kernel-2.4.21-20ELsmp apart from CONFIG_ACPI=y. This does
seem to work OK.

I know there are some peculiarities with the RHEL3 ACPI implementation
which mean that CONFIG_ACPI isn't set on ix86. What are the chances
that this board could be used under RHEL3? If none, someone should let
Supermicro know as they're advertising it as RHEL3 compatible!

Comment 7 John W. Linville 2004-11-09 14:04:09 UTC
It may be worth trying to manually assign interrupt values for the
e1000 cards in the BIOS -- not sure why Nahant would fair any better
than RHEL3, but still...

http://support.intel.com/support/network/adapter/1000mtquad/sb/CS-009534.htm#knownissues

Shared Interrupt Limitation
In some systems, the BIOS and OS assign the same interrupt number to
two or more different ports on the Intel PRO/1000 MT Quad Port Server
Adapter. If this occurs, these ports do not function properly. In this
case, reassign the system resources so that each port of the adapter
has its own unique interrupt number or disable one of the ports
sharing the same interrupt number.

Comment 8 Robert Clark 2004-11-10 01:07:38 UTC
Unfortunately, I've run out of time for this and have had to put the
server into service with Fedora Core 2 but, if I remember correctly,
the BIOS only offered the ability to mark interrupts as reserved, not
manually assign them.

I'm assuming that the reason Nahant works is that its kernel is
compiled with CONFIG_ACPI=y.

Comment 9 John W. Linville 2004-11-17 20:27:36 UTC
I think you are right about CONFIG_ACPI...unfortunately, the
CONFIG_ACPI is unlikely to ever be turned-on in RHEL3.

I have to recommend FC2/3 and RHEL4 when it is available...


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