Bug 101101 - (ACPI) SCI interrupt storm on Tyan Tiger/VIA Apollo; no e100 interrupts
(ACPI) SCI interrupt storm on Tyan Tiger/VIA Apollo; no e100 interrupts
Status: CLOSED UPSTREAM
Product: Red Hat Linux Beta
Classification: Retired
Component: kernel (Show other bugs)
beta1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Brian Brock
:
Depends On:
Blocks: CambridgeTarget
  Show dependency treegraph
 
Reported: 2003-07-28 23:06 EDT by Howard Owen
Modified: 2013-07-02 22:13 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-03-03 03:42:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output from dmidecode and acpidmp on tmy system after booting with acpi=no (45.28 KB, text/plain)
2003-07-28 23:08 EDT, Howard Owen
no flags Details
dmesg output and /proc/interrupt contents (40.00 KB, application/octet-stream)
2003-07-31 01:39 EDT, Howard Owen
no flags Details
ACPI patch for VT86/Award interrupt problem. (12.21 KB, patch)
2003-08-21 18:16 EDT, Len Brown
no flags Details | Diff
sci_trigger.patch (3.27 KB, patch)
2003-09-07 00:12 EDT, Len Brown
no flags Details | Diff

  None (edit)
Description Howard Owen 2003-07-28 23:06:35 EDT
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:
Comment 1 Howard Owen 2003-07-28 23:08:47 EDT
Created attachment 93211 [details]
Output from dmidecode and acpidmp on tmy system after booting with acpi=no
Comment 2 Michael Young 2003-07-29 08:16:52 EDT
duplicate of bug 100522 (or vice versa)?
Comment 3 Len Brown 2003-07-31 01:13:27 EDT
Please snag the output from:
/sbin/dmesg -s40000
cat /proc/interrupts
for the default (failing) and the acpi=off (success) case.
Comment 4 Howard Owen 2003-07-31 01:39:11 EDT
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
Comment 5 Len Brown 2003-08-05 17:15:23 EDT
< 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? 
 
 
Comment 6 Howard Owen 2003-08-10 15:43:39 EDT
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)
Comment 7 Len Brown 2003-08-21 18:16:26 EDT
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
Comment 8 Len Brown 2003-09-03 13:11:36 EDT
> 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. 
 
 
 
Comment 9 Howard Owen 2003-09-03 13:52:51 EDT
I'll try that patch later this week. I somehow missed the
bugzilla update mail when it was posted.
Comment 10 Len Brown 2003-09-07 00:12:57 EDT
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.
Comment 11 Jeff Garzik 2004-03-03 03:42:35 EST
No response in a while, will assume the patch fixed things.  Re-open
bug against Fedora Core (after testing), if problem persists.

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