Bug 1165

Created attachment 762 [details]
dmesg and acpidmp

Created attachment 764 [details]
dmesg booting with acpi

Distro: Gentoo
Hardware Environment: Asus P4T533-C
                      Intel P4 2.4 GHz
                      3Com 3c905B NIC
                      Adaptec AIC-7892A U160/m (rev 02)
                      etc..

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

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

           CPU0       
  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.

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
[0x3])

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"?

Please try patch for bug #774, I want to see what could happen, if irq for SCI 
gets changed. 

Created attachment 796 [details]
lspci in APIC mode without acpi

Created attachment 797 [details]
/proc/interrupts with acpi enabled in PIC mode

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...

> 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. 
 
 

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?

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?

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...

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

 
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. 
http://www.asus.com/pub/ASUS/mb/sock478/p4t533/e1109_p4t533.pdf 
 
 
 

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
much...:-/

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

Thank you

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*/ /********/
	continue;
} /*****/

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.

yes, if you can attach the full dmesg resulting from applying just shaohua's patch, 
we can probably put this one to bed.  thanks. 
 

Created attachment 904 [details]
dmesg entry->irq set