From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131 Description of problem: On my dual PIII/800 system (using a Tyan S1834D, Via based mobo) and two known good Intel ee100 NICs, I couldn't get them to work under severn. They configured OK, ethtool showed good status, but no data would flow. It looked like a duplex problem since I would see the packet count go up on either Rx or Tx, but not both. Changing to half duplex using ethtool did not address the problem. Switching to the eepro100 driver from ee100 didn't help either. I asked about it on #rhl_devel, and Notting suggested I disable ACPI with acpi=no in grub.conf. That fixed the problem on reboot. I'm filing this bug at his request, and attaching the output of dmidecode and acpidmp Version-Release number of selected component (if applicable): kernel-smp-2.4.21-20.1.2024.2.1.nptl How reproducible: Always Steps to Reproduce: 1. Using identical hardware to mine, boot severn without passing acpi=no to the kernel. 2. Observe that the NIC doesn't work. Actual Results: The NIC doesn't work. Expected Results: The NIC should work. Additional info:
Created attachment 93211 [details] Output from dmidecode and acpidmp on tmy system after booting with acpi=no
duplicate of bug 100522 (or vice versa)?
Please snag the output from: /sbin/dmesg -s40000 cat /proc/interrupts for the default (failing) and the acpi=off (success) case.
Created attachment 93287 [details] dmesg output and /proc/interrupt contents This is a tarball containing the following files: dmesg-acpi-off dmesg-acpi-on proc-interrupts-acpi-off proc-interrupts-acpi-on
< acpi=off > acpi enabled --- < 11: 2622722 13 IO-APIC-level usb-uhci, eth0 > 11: 0 0 IO-APIC-edge usb-uhci, eth0 The acpi case set this interrupt to edge, which is why your I/F doesn't work -- should be level sensitive. --- < 10: 7 18 IO-APIC-level EMU10K1 > 9: 9199704 5361210 IO-APIC-level acpi Curious that the Creative EMU10K1 Sound doesn't show up in the ACPI config. Even more curious that the ACPI config is getting lots of ACPI interrupts! --- dmesg... Processor #0 Pentium(tm) Pro APIC version 17 Processor #1 Pentium(tm) Pro APIC version 17 Are you sure this is a Pentium III system? --- ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: System [ACPI] (supports S0 S1 S4bios S5) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 11 12 14 15, disabled) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 11 12 14 15, disabled) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) PCI: Probing PCI hardware PCI: ACPI tables contain no PCI IRQ routing entries PCI: Using IRQ router VIA [1106/0596] at 00:07.0 PCI BIOS passed nonexistent PCI bus 0! PCI BIOS passed nonexistent PCI bus 0! PCI BIOS passed nonexistent PCI bus 0! PCI BIOS passed nonexistent PCI bus 1! PCI BIOS passed nonexistent PCI bus 0! This sure doesn't look promising;-) The system is loading _both_ e100 and eepro100 for eth0? Can you send the output from lspci? I suspect your system will boot with 'linux pci=noacpi' can you verify this?
The system has 2 PIII/800EB processors. pci=noacpi does not solve the NIC problem e100pro driver was in modules.conf as a result of my testing. I've removed it now. I don't use the sound card, so I wasn't aware it was wonky. [root@mycop root]# lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] (rev 23) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 11) 00:07.3 Host bridge: VIA Technologies, Inc. VT82C596 Power Management (rev 30) 00:0f.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 00:10.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 05) 00:10.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 05) 01:00.0 VGA compatible controller: nVidia Corporation NV5 [RIVA TNT2/TNT2 Pro] (rev 11)
Created attachment 93836 [details] ACPI patch for VT86/Award interrupt problem. This patch has fixed the ACPI interrupt problem for similar systems. Please try applying it to a copy of your Severn BETA1 kernel to see if works for you too: ~/src/linux-2.4.21-20.1.2024.2.1.nptl> patch -Np1 < ./pci_link-severn.patch patching file arch/i386/kernel/io_apic.c patching file arch/i386/kernel/mpparse.c patching file drivers/acpi/pci_irq.c patching file drivers/acpi/pci_link.c patching file include/acpi/acpi_drivers.h
> 9: 9199704 5361210 IO-APIC-level acpi This interrupt storm may be caused by an eth0 interrupt on IRQ9 that acpi can't handle. Or it may be caused by an incorrect polarity on the SCI. > ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x1] trigger[0x3]) says the polarity 0x1 should be active high -- the opposite from PCI interrupts.
I'll try that patch later this week. I somehow missed the bugzilla update mail when it was posted.
Created attachment 94283 [details] sci_trigger.patch The earlier patch may address your ethernet interrupt problem, but I don't expect it will address your acpi interrupt storm problem because your SCI over-ride is acive _high_ and we used to hard-code assuming spec compliance of active _low_. So please also apply this patch and see if it helps the acpi interrupt storm.
No response in a while, will assume the patch fixed things. Re-open bug against Fedora Core (after testing), if problem persists.