Questions to ACPI, Interrupts, APICS (M57SLI)

[Harald Gutmann]

Hello,

a few days ago i happily sent a patch for fixing the PCI-issues on the m57sli 
to the list.
After some further tests, i just have gotten more questions, and nothing seems 
to be "really" fixed.

I attached two patches, one corrects just the GPIOS and does some changes to 
mptable.c, but nothing special.
The second corrects the GPIO stuff, and adds acpi support to the m57sli.

Now i've the following situation:
With the first patch (GPIO, mptable) nothing is "really" fixed, because PCI-E 
doesn't receive interrupts, and also another PCI-slot has interrupt problems.

Here is for example a little output from the dmesg according to interrupts:
"[   31.542432] Pid: 0, comm: swapper Tainted: P          2.6.26-1-amd64 #1
[   31.542434]
[   31.542435] Call Trace:
[   31.542436]  <IRQ>  [<ffffffff8026c6c3>] __report_bad_irq+0x30/0x72
[   31.542459]  [<ffffffff8026c902>] note_interrupt+0x1fd/0x23b
[   31.542464]  [<ffffffff8026d18b>] handle_fasteoi_irq+0xa5/0xc8
[   31.542468]  [<ffffffff8020f5e4>] do_IRQ+0x6d/0xd9
[   31.542470]  [<ffffffff8020b0a3>] default_idle+0x0/0x49
[   31.542472]  [<ffffffff8020c46d>] ret_from_intr+0x0/0x19
[   31.542474]  <EOI>  [<ffffffff8021eb54>] native_safe_halt+0x2/0x3
[   31.542481]  [<ffffffff8021eb54>] native_safe_halt+0x2/0x3
[   31.542484]  [<ffffffff8020b0cd>] default_idle+0x2a/0x49
[   31.542486]  [<ffffffff8020ac79>] cpu_idle+0x89/0xb3
[   31.542493]
[   31.542494] handlers:
[   31.542495] [<ffffffffa02a6b8d>] (snd_ice1712_interrupt+0x0/0x1c2 
[snd_ice1712])
[   31.542507] Disabling IRQ #19"

(Ideas for fixing that problem? This device is on a pci-slot, and has in 
mptable.c irq 19 assigned. Therefore i don't see in CB-code what could be done 
to fix it.)

With the second patch, including ACPI with the original (proprietary) dsdt.asl 
file, everything works fine.
The PCI-E graphic card works like a charm, there are no strange messages 
according to IRQ19 in the dmesg, ...

So now my basic question is:
What does the acpi part do, to get all the IRQ's correct? Why doesn't that 
work without ACPI support? (Is this maybe done in the dsdt.asl?)

Where do i have to correct things, to get PCI/PCI-E interrupts correct, and 
without ACPI?

Kind Regards,
Harald Gutmann

[Peter Stuge]

Harald Gutmann wrote:
> What does the acpi part do, to get all the IRQ's correct?

At the very least it provides documentation about how hardware is
connected, and about how the firmware has configured the hardware
with regard to interrupt routing. (Between the interrupt pins in the
PCI slots, and the software interrupt handler there is a fairly long
way with several opportunities for mapping.)
> Why doesn't that work without ACPI support?
> (Is this maybe done in the dsdt.asl?)

Yes, the DSDT shows the interrupt routing. I guess the mptable isn't
correct - ie. it does not say the same thing as the factory DSDT.
> Where do i have to correct things, to get PCI/PCI-E interrupts
> correct, and without ACPI?

First step make the mptable say what the DSDT says. It seems you're
on your way already.

It would of course also help to be able to debug all that interrupt
mapping, but without real chipset docs we are SOL.

//Peter

[Harald Gutmann]

On Friday 27 March 2009 09:02:21 Peter Stuge wrote:
> Harald Gutmann wrote:
> > What does the acpi part do, to get all the IRQ's correct?
>
> At the very least it provides documentation about how hardware is
> connected, and about how the firmware has configured the hardware
> with regard to interrupt routing. (Between the interrupt pins in the
> PCI slots, and the software interrupt handler there is a fairly long
> way with several opportunities for mapping.)
> > Why doesn't that work without ACPI support?
> > (Is this maybe done in the dsdt.asl?)
>
> Yes, the DSDT shows the interrupt routing. I guess the mptable isn't
> correct - ie. it does not say the same thing as the factory DSDT.

Okay, it seems that my assumption that the DSDT is the "problem-solver" in the 
patch with the ACPI part was right.
Now i should really try to read and understand that long (+3k lines) file, and 
until now, i don't understand much of that what is written there. (I guess 
that the ACPI-reference will be the thing i'm going to read the next days. ;))
> > Where do i have to correct things, to get PCI/PCI-E interrupts
> > correct, and without ACPI?
>
> First step make the mptable say what the DSDT says. It seems you're
> on your way already.

Could get quite hard, even if it soulds really easy, but i think that i can 
handle that.
> It would of course also help to be able to debug all that interrupt
> mapping, but without real chipset docs we are SOL.
>
> //Peter

Thanks Peter!

Kind Regards,
Harald

[Rudolf Marek]

Hi,

http://www.coreboot.org/ACPI_in_coreboot
Check this.

All you need is to get the information for _PRT method routings. Then you can 
construct some minimalistic DSDT as I did for m2v-mx.

If you need help, just write/ask here.

Rudolf

[Harald Gutmann]

On Friday 27 March 2009 10:30:22 Rudolf Marek wrote:
> Hi,
>
> http://www.coreboot.org/ACPI_in_coreboot
> Check this.

I know that site, but that is ATM not the problem i'm going to address. (This 
will happen later on.)

The problem which actually exists on M57SLI is, that one PCI port and the 
PCI-16x port isn't working correctly.
Therefore it's necessary to fix the mptable.c file, so that those ports will be 
initialized correctly from coreboot.

Like Peter said, it should be possible to get the right values which are 
needed in the mptable.c out of the vendors DSDT file, but my problem is right 
now, that i don't know the ACPI specifications (DSDT parts) that good, to be 
able to find out which parts of the DSDT are relevant for fixing the PCI issues 
on M57SLI.
> All you need is to get the information for _PRT method routings. Then you
> can construct some minimalistic DSDT as I did for m2v-mx.

Good that you mention that again, maybe i shall look out for the _PRT symbols 
on the vendors DSDT, which i also attached.
Maybe you can give a look at that file, and give me a hint which parts are 
relevant to fix my problem.
> If you need help, just write/ask here.
>
> Rudolf

Thanks.

Kind regards
Harald

[Rudolf Marek]

Hello,

Please send me lspci output and attach the grep of IRQ from running kernel with 
working PCIe interrupts.

marekr2@queeg:~$ dmesg | grep IRQ

Thanks,

Rudolf

[Harald Gutmann]

On Friday 27 March 2009 11:18:11 Rudolf Marek wrote:
> Hello,
>
> Please send me lspci output and attach the grep of IRQ from running kernel
> with working PCIe interrupts.

Informations attached.
The lspci_vendor_verbose.txt file, contains the lspci output with "-vvv -xxx" 
options.
> marekr2@queeg:~$ dmesg | grep IRQ
>
> Thanks,
>
> Rudolf

Thanks,
Harald

[Rudolf Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

It will take more time because you need to have the dynamic IRQ model.

here is the layout offset at 0x7c, each 4 bits:

OperationRegion (PIRQ, PCI_Config, 0x7C, 0x0C)
                Scope ()
                {
                    Field (_SB.PCI0.LEG0.PIRQ, AnyAcc, NoLock, Preserve)
                    {
                        INTA,   4,
                        INTB,   4,
                        INTC,   4,
                        INTD,   4,
                        PCEA,   4,
                        PCEB,   4,
                        PCEC,   4,
                        PCED,   4,
offset 0x80:
- -> this is ACPI IRQ     SCII,   4,
- -> This is watchdog?    TCOI,   4,
                        INTF,   4,
                        INTQ,   4,
                        INTU,   4,
                        INTS,   4,
                        IS0P,   4,
                        ITID,   4,
                        INTG,   4,
                        INTH,   4,
                        INTJ,   4,
                        INTK,   4,
                        INTL,   4,
                        INTM,   4,
                        INTN,   4,
                        ISA2,   4
                    }

I will look into this soon.

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknOPrgACgkQ3J9wPJqZRNWfuACg4rrIitWBx8JgK6J26rGLY5ai
WT4AoLXEY37yQqiqJ2z7VveRg6IKNuGV
=6Z06
-----END PGP SIGNATURE-----

[Rudolf Marek]

Hi,

I'm attaching the mappings derived from the original DSDT. It cost me mine 
wallet (stolen in train :/ ), so I hope it is for something.

You can go for static mappings as described in the Wiki page, all you need to 
setup the regs from 0x7c to 0x87 and then define the static packages in ACPI (or 
fix the regs to fit MPtable as final shortcut).

Rudolf

Register to IRQ mappings

4bit / IRQ hex - dec

0x00 - disabled

0x01 - IRQ 0x17 - 23
0x02 - IRQ 0x16 - 22
0x03 - IRQ 0x10 - 16
0x04 - IRQ 0x11 - 17
 0x05 - IRQ 0x05 -  5
0x06 - IRQ 0x12 - 18
 0x07 - IRQ 0x7  - 7
0x08 - IRQ 0x14 - 20
 0x09 - IRQ 0x09 - 9
 0x0A - IRQ 0x0a - 10
 0x0B - IRQ 0x0b - 11
0x0C - IRQ 0x13 - 19
0x0D - IRQ 0x15 - 21
 0x0E - IRQ 0x0E - 14
 0x0F - IRQ 0x0F - 15

Register layout:

Each line is 4 bits.

0x7C
INTA
INTB
INTC
INTD
PCEA
PCEB
PCEC
PCED

0x80
SCII (ACPI IRQ)
TCOI (Watchdog?)
INTF
INTQ
INTU
INTS
IS0P
ITID

0x84
ITID
INTG
INTH
INTJ
INTK
INTL
INTM
INTN
ISA2

Device/pin

1/INTA (ISALPC) -> INTF
1/INTB (SMBUS) -> INTS

2/INTA (USB0) ->INTG
2/INTB (USB1) -> INTQ
8/INTA (Ethernet) -> INTJ

4/INTA (IDE) -> INTN

5/INTA (SATA1) -> ITID
5/INTB (SATA2) -> IS0P
5/INTC (SATA3) -> ISA2

6/INTA (Bridge?) -> INTU
6/INTB (Audio) -> INTK

F/INTA -> PCEB
F/INTB -> PCEC
F/INTC -> PCED
F/INTD -> PCEA

E/INTA -> PCEC
E/INTB -> PCED
E/INTC -> PCEA
E/INTD -> PCEB

D/INTA -> PCED
D/INTB -> PCEA
D/INTC -> PCEB
D/INTD -> PCEC

C/INTA -> PCEA
C/INTB -> PCEB
C/INTC -> PCEC
C/INTD -> PCED

B/INTA -> PCEB
B/INTB -> PCEC
B/INTC -> PCED
B/INTD -> PCEA

A/INTA -> PCEC
A/INTB -> PCED
A/INTC -> PCEA
A/INTD -> PCEB

Bus behind bridge from device 6:
this is bus 1:

6/INTA -> INTC
6/INTB -> INTD
6/INTC -> INTA
6/INTD -> INTB

7/INTA -> INTD
7/INTB -> INTA
7/INTC -> INTB
7/INTD -> INTC

8/INTA -> INTA
8/INTB -> INTB
8/INTC -> INTC
8/INTD -> INTD

9/INTA -> INTB
9/INTB -> INTC
9/INTC -> INTD
9/INTD -> INTA

A/INTA -> INTC
A/INTB -> INTD
A/INTC -> INTA
A/INTD -> INTB

The Graphic card is through bridge 0xF
Perhaps it uses routing of device 0xF on bus 0