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)
Created attachment 105900 [details] dmesg info Attaching some information from dmesg
Created attachment 105901 [details] lspci info Attaching output from lspci -v
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.
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?
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.
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!
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.
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.
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...