Bug 1165 - 2.4.22 IO-APIC ACPI SCI but no eth0 interrupts
Summary: 2.4.22 IO-APIC ACPI SCI but no eth0 interrupts
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Shaohua
Depends on:
Reported: 2003-08-28 18:57 UTC by Luming Yu
Modified: 2004-03-03 22:07 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.4.22
Regression: ---
Bisected commit-id:

dmesg and acpidmp (45.98 KB, application/octet-stream)
2003-08-28 18:59 UTC, Luming Yu
dmesg booting with acpi (14.99 KB, text/plain)
2003-08-29 05:15 UTC, Marc Giger
lspci in APIC mode without acpi (7.04 KB, text/plain)
2003-09-03 01:57 UTC, Marc Giger
/proc/interrupts with acpi enabled in PIC mode (450 bytes, text/plain)
2003-09-03 01:57 UTC, Marc Giger
dmesg with SCI patch (13.67 KB, text/plain)
2003-09-03 02:26 UTC, Marc Giger
/proc/interrupts with usb nvidia etc... (618 bytes, text/plain)
2003-09-03 02:37 UTC, Marc Giger
dmesg with CONFIG_ACPI_DEBUG on (18.24 KB, text/plain)
2003-09-03 03:33 UTC, Marc Giger
right dmesg but cutted (15.01 KB, text/plain)
2003-09-03 11:22 UTC, Marc Giger
IRQ routing with entry->irq set (534 bytes, text/plain)
2003-09-05 01:26 UTC, Marc Giger
dmesg entry->irq set (14.38 KB, text/plain)
2003-09-18 00:39 UTC, Marc Giger

Description Luming Yu 2003-08-28 18:57:47 UTC
Hardware Environment:
Software Environment:
Problem Description:
Steps to reproduce:
Comment 1 Luming Yu 2003-08-28 18:59:25 UTC
Created attachment 762 [details]
dmesg and acpidmp
Comment 2 Marc Giger 2003-08-29 05:15:06 UTC
Created attachment 764 [details]
dmesg booting with acpi
Comment 3 Marc Giger 2003-08-29 05:32:41 UTC
Distro: Gentoo
Hardware Environment: Asus P4T533-C
                      Intel P4 2.4 GHz
                      3Com 3c905B NIC
                      Adaptec AIC-7892A U160/m (rev 02)

Software Env: Kernel: vanilla 2.4.22 / 2.6.0-testX
Problem Description: 
#1: High interrupt rate:

11:43:53 up 12 min,  0 users,  load average: 0.32, 0.63, 0.39

  0:      73491    IO-APIC-edge  timer
  1:       3783    IO-APIC-edge  keyboard
  2:          0          XT-PIC  cascade
  8:          2    IO-APIC-edge  rtc
  9:          2    IO-APIC-edge  eth0
 14:        919    IO-APIC-edge  ide0
 15:          9    IO-APIC-edge  ide1
 20:      11779   IO-APIC-level  aic7xxx
 22:   60376810   IO-APIC-level  acpi
NMI:          0 
LOC:      73449 
ERR:          0
MIS:          0

This high interrupt rate slowdowns the box noticeable.

#2 eth0 doesn't work if acpi enabled. See attached dmesg

#3 When I type pci=noacpi on lilo prompt then I can't boot the machine. It
hangs while detecting the scsi drives on aic7xxx.
Comment 4 Len Brown 2003-09-02 22:46:12 UTC
Hmmm, ACPI taking zillion interrupts on IRQ22 and eth0 taking none on IRQ9....

FADT (byte offset 46) specifies that the ACPI SCI comes in on PIC IRQ 9.
MADT, however, over-rides this and maps IRQ9 to IRQ22 in IO-APIC mode:

> ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x16] polarity[0x3] trigger

But then:
> PCI: No IRQ known for interrupt pin A of device 02:0a.0

If this is eth0, it is unclear how it got here, and how it ended up on IRQ 9.
Can you attach the output from lspci -vv?

I assume the devices work if you force PIC mode and boot with cmdline "noapic"?
Comment 5 Luming Yu 2003-09-03 00:19:54 UTC
Please try patch for bug #774, I want to see what could happen, if irq for SCI 
gets changed. 
Comment 6 Marc Giger 2003-09-03 01:57:00 UTC
Created attachment 796 [details]
lspci in APIC mode without acpi
Comment 7 Marc Giger 2003-09-03 01:57:54 UTC
Created attachment 797 [details]
/proc/interrupts with acpi enabled in PIC mode
Comment 8 Marc Giger 2003-09-03 01:58:17 UTC
When I boot with noapic it works with and without acpi.
In PIC mode there is a different IRQ routing with and without acpi.
attached as requested lspci (apic) and /proc/interrupts in PIC mode

I will try the SCI patch in a few minutes...
Comment 9 Len Brown 2003-09-03 02:09:28 UTC
> 02:0a.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev
> 34) 
>       Interrupt: pin A routed to IRQ 22 
I think that you're getting an eth0 interrupt on IRQ22, but eth0 is not there to handle it, 
and acpi can't, so it never goes away. 
Assuming that IRQ22 is PIRQG, then your NIC would be in slot 2 -- which shares interrupts 
with USB and Promise.  I expect that USB and Promise don't work either;-O 
I expect that if you move your NIC to another slot, that it will work. 
The question is why eth0 ended up on IRQ9.  Please add CONFIG_ACPI_DEBUG to the 
failing configuration and perhaps dmesg will tell us why.  I suspect we have a bug when 
the board is wired to share SCI with a PCI device on the same IRQ in IO-APIC mode. 
Comment 10 Marc Giger 2003-09-03 02:26:36 UTC
Created attachment 798 [details]
dmesg with SCI patch

Yo, it seems to works with the SCI patch.

A question: Why do you assign interrupt 11 statically to acpi? Can't it
assigned dynamically? What happens if irq 11 assigned to a device? Conflict?
Interrupt sharing?
Comment 11 Marc Giger 2003-09-03 02:37:56 UTC
Created attachment 799 [details]
/proc/interrupts with usb nvidia etc...

No you are wrong luckily;-) All things are working USB NVIDIA etc...
What i don't have tested is the isdn card...but I think it will work too..

Should I test "CONFIG_ACPI_DEBUG" with the SCI patch applied?
Comment 12 Marc Giger 2003-09-03 02:42:28 UTC
Where do you see promise? I think I don't have such shity hardware...;-)

And I can't test NIC in another slot, all are full:-(

What I have tried a long time ago, is to find out the best combination with the
cards, so that nothing shares an irq with another device...
Comment 13 Marc Giger 2003-09-03 03:33:08 UTC
Created attachment 803 [details]
dmesg with CONFIG_ACPI_DEBUG on

I had to take the messages from  /var/log/messages because the dmesg buffer was
to  short. I hope there are all infos too
Comment 14 Len Brown 2003-09-03 10:30:07 UTC
Sep  3 12:17:21 hdg kernel:  pci_irq-0302 [17] acpi_pci_irq_derive   : Unable to derive IRQ for 
device 02:0a.0 
Sep  3 12:17:21 hdg kernel: PCI: No IRQ known for interrupt pin A of device 02:0a.0 
Sep  3 12:17:21 hdg kernel:  pci_irq-0302 [16] acpi_pci_irq_derive   : Unable to derive IRQ for 
device 02:0a.0 
Sep  3 12:17:21 hdg kernel: PCI: No IRQ known for interrupt pin A of device 02:0a.0 
may need to add some debug code to get to the cause. 
I'm not positive that /var/log/messags gets everything. 
note that dmesg with a size argument, say dmesg -s 40000 may get back to the beginning. 
BTW. I found Promise on PIRQG on the interrupt table in the ASUS P4T533 user manual. 
Shares an interrupt with PCI slot 2 and the USB 2.0.  Maybe Promise is a MB option. 
Comment 15 Marc Giger 2003-09-03 11:22:49 UTC
Created attachment 806 [details]
right dmesg but cutted

Len, notice I have P4T533-C. There are little differences between them.

I know "dmesg -s". I tried it with factors of ten. Perhaps it was too

Anyway, I will wait with further testing until you sent me the patch with more
debug code, which you mentioned.

Thank you
Comment 16 Shaohua 2003-09-04 19:01:03 UTC
can you try this: 
    add below lines with '/****/' into routine 'mp_parse_prt' of 
file 'mpparse.c' 

/* Don't set up the ACPI SCI because it's already set up */
if (acpi_fadt.sci_int == irq)
{  /*****/
        entry->irq = irq; /*we still need to set entry's irq*/ /********/
} /*****/
Comment 17 Marc Giger 2003-09-05 01:26:58 UTC
Created attachment 818 [details]
IRQ routing with entry->irq set

This seems to work. No problem yet.
If you need full dmesg I will attach it.
Comment 18 Len Brown 2003-09-17 16:15:24 UTC
yes, if you can attach the full dmesg resulting from applying just shaohua's patch, 
we can probably put this one to bed.  thanks. 
Comment 19 Marc Giger 2003-09-18 00:39:45 UTC
Created attachment 904 [details]
dmesg entry->irq set

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