Re: Possible quick fix for ACPI routing problem on Nforce2

Re: Possible quick fix for ACPI routing problem on Nforce2

[Andrew de Quincey]

Hi, I've been playing about with this, and I've found what is happening.
I've not yet tracked down the reason yet, but if anyone else has this
problem, can they try please this fix to see if it is consistent.

Anyway, IRQs > 15 get set to Active low/Level Sensitive in the IO-APIC on
my board.

The fix (No patch as this is NOT a proper fix):
Edit arch/i386/kernel/io_apic.c
Find the function io_apic_set_pci_routing() (its the last one in 2.5.74).
Change the line:
entry.polarity = 1;         /* Low active */

To:
entry.polarity = 0;         /* High active */

For me, this makes everything work fine. Originally, I also forced these
IRQs to be edge sensitive, but leaving them at level seems to work fine as
well.

Now, I assume one of the other functions in io_apic.c is _meant_ to be
called to set this correctly. My next step is to track down why this is not
occurring.

A question: Why are these set to level/activelow in a function which is
labelled to be setting up PCI IRQs? I'd assumed they were always
edge/active high.. or is this not necessarily the case?



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Re: Possible quick fix for ACPI routing problem on Nforce2

[Jurriaan]

From: Andrew de Quincey <adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org>
Date: Sun, Jul 13, 2003 at 02:18:44AM +0100
> Hi, I've been playing about with this, and I've found what is happening.
> I've not yet tracked down the reason yet, but if anyone else has this
> problem, can they try please this fix to see if it is consistent.
> 
> Anyway, IRQs > 15 get set to Active low/Level Sensitive in the IO-APIC on
> my board.
> 
> The fix (No patch as this is NOT a proper fix):
> Edit arch/i386/kernel/io_apic.c
> Find the function io_apic_set_pci_routing() (its the last one in 2.5.74).
> Change the line:
> entry.polarity = 1;         /* Low active */
> 
> To:
> entry.polarity = 0;         /* High active */
> 
> For me, this makes everything work fine. Originally, I also forced these
> IRQs to be edge sensitive, but leaving them at level seems to work fine as
> well.
> 
No joy on VIA KT400 chipset (bugzilla #678): ide0 get's IRQ 17, during
boot multiple oopses occur, starting with 'IRQ 17: nobody cared' right
after probing hda. Eventually it crashes hard, after probing hde.

Thanks,
Jurriaan
-- 
Pay attention, the wreckage seemed to declare. Some things cannot be
undone, short of time pivoting in its groove and crawling back on itself.
	Tad Williams - Otherland
Debian (Unstable) GNU/Linux 2.5.75 4112 bogomips load av: 1.06 0.44 0.16


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Re: Possible quick fix for ACPI routing problem on Nforce2

[liste-9nAOAgdJVo4b1SvskN2V4Q]

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

Salut Andrew,
On Sun, 13 Jul 2003, Andrew de Quincey wrote:
> Anyway, IRQs > 15 get set to Active low/Level Sensitive in the IO-APIC on
> my board.
>
> The fix (No patch as this is NOT a proper fix):
> Edit arch/i386/kernel/io_apic.c
> Find the function io_apic_set_pci_routing() (its the last one in 2.5.74).
> Change the line:
> entry.polarity = 1;         /* Low active */
>
> To:
> entry.polarity = 0;         /* High active */
>
> For me, this makes everything work fine. Originally, I also forced these
> IRQs to be edge sensitive, but leaving them at level seems to work fine as
> well.
Only ISA-IRQs are edge ones. As PCI has interrup-sharing, they need to be
level ones. I am pretty sure, that your irq > 15 are not for ISA
devices...

cheers
  hartwig felger

Hartwig Felger informatics

- -- 
1024D/339FD693 Hartwig Felger <hgfelger-9nAOAgdJVo4b1SvskN2V4Q@public.gmane.org>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/ESQP9bBoTzOf1pMRAjJVAJ99bGTXXRiw/iBojCWYDiNNMtrUbQCg4XcL
merVrl51er6HGA9qFIk0gig=
=H/M+
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Re: Possible quick fix for ACPI routing problem on Nforce2

[Andrew de Quincey]

On Sunday 13 July 2003 10:19, liste-9nAOAgdJVo4b1SvskN2V4Q@public.gmane.org wrote:
> Salut Andrew,
>
> On Sun, 13 Jul 2003, Andrew de Quincey wrote:
> > Anyway, IRQs > 15 get set to Active low/Level Sensitive in the IO-APIC on
> > my board.
> >
> > The fix (No patch as this is NOT a proper fix):
> > Edit arch/i386/kernel/io_apic.c
> > Find the function io_apic_set_pci_routing() (its the last one in 2.5.74).
> > Change the line:
> > entry.polarity = 1;         /* Low active */
> >
> > To:
> > entry.polarity = 0;         /* High active */
> >
> > For me, this makes everything work fine. Originally, I also forced these
> > IRQs to be edge sensitive, but leaving them at level seems to work fine
> > as well.
>
> Only ISA-IRQs are edge ones. As PCI has interrup-sharing, they need to be
> level ones. I am pretty sure, that your irq > 15 are not for ISA
> devices...

OK, makes sense.

Interesting. I see the polarity is hardcoded to active low (1) in the code, 
which is correct for PCI isn't it?

BUT: this just does not work in my system. The onboard nforce2 devices are 
generating active high IRQs, yet are mapped to IRQs 20,21,22 in ACPI. I've 
checked in Windows: it works, and those devices are mapped to IRQs 20,21,22 
as well.



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Re: Possible quick fix for ACPI routing problem on Nforce2

[Andrew de Quincey]

Can you send me the contents of your /proc/acpi/dsdt if possible? I'd like to 
see if you have non-PCI-standard IRQs in the _PRT tables like I do.



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Re: Possible quick fix for ACPI routing problem on Nforce2

[Andrew de Quincey]

> No joy on VIA KT400 chipset (bugzilla #678): ide0 get's IRQ 17, during
> boot multiple oopses occur, starting with 'IRQ 17: nobody cared' right
> after probing hda. Eventually it crashes hard, after probing hde.

I think this is related to the same problem. I've looked at your DSDT dump. It 
doesn't have the same style of IRQ definitions that mine has... It defines 
most of your IRQs as being connected to specific global system interrupt 
numbers (p165, ACPI v2.0b) (Mine has all interrupts directed at link 
devices).

However, IRQ 17 will be set up as a PCI-standard IRQ... So its _probably_ that 
the first IDE device is expecting a different signalling standard to that 
which it is getting... If you were able to get to a command prompt you'd 
probably see /proc/interrupts showing millions of spurious IRQs like I did.



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Re: Possible quick fix for ACPI routing problem on Nforce2

[Andrew de Quincey]

> No joy on VIA KT400 chipset (bugzilla #678): ide0 get's IRQ 17, during
> boot multiple oopses occur, starting with 'IRQ 17: nobody cared' right
> after probing hda. Eventually it crashes hard, after probing hde.

Looking at your dmesg dump from 2.5.75, another problem is here, where it 
tries to route lots of your PCI IRQs to IRQ 0. It seems to be failing to 
program the IRQs. No idea why yet. 

BTW: is there a way to get more detailed debug output on ACPI? There are loads 
more debugging print statements in the code than are appearing in your dmesg 
(or in mine as well) even with ACPI Debug statements turned on.

pci_link-0256 [21] acpi_pci_link_get_curr: No IRQ resource found 
ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 0
pci_link-0256 [22] acpi_pci_link_get_curr: No IRQ resource found
ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 0
pci_link-0256 [23] acpi_pci_link_get_curr: No IRQ resource found
ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 0
pci_link-0256 [24] acpi_pci_link_get_curr: No IRQ resource found
ACPI: PCI Interrupt Link [ALKD] enabled at IRQ 0



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Located the problem with the VIA KT400 board

[Andrew de Quincey]

Hi, I think I've just spotted the problem, and unfortunately, I think it is an 
AML problem.

When your board boots, several devices are configured without IRQs set (i.e. 
the IRQ returned by _CRS is 0) (I think this is called "boot disabled 
devices"). They have a list of possible IRQs (all of them > 15) in _PRS.

The linux code for setting an IRQ is in 
drivers/acpi/pci_link.c/acpi_pci_link_set().
Theres a wee fix to make in here for my patch for the polarity etc, but your 
problem is when it creates the resource entry to send to the _SRS method.

It does something like:
if (irq <= 15) {
  ... create an IRQ resource
} else {
  ... create an extended IRQ resource
}

However, the _SRS code in your BIOS has the following for the relevant 
devices:

            Method(_SRS, 1) {
                CreateByteField(Arg0, 0x1, IRD1)
                CreateByteField(Arg0, 0x2, IRD2)
                ShiftLeft(IRD2, 0x8, Local0)
                Or(Local0, IRD1, Local0)
                Store(0x0, Local1)
                ShiftRight(Local0, 0x1, Local0)
                While(LGreater(Local0, 0x0)) {
                    Increment(Local1)
                    ShiftRight(Local0, 0x1, Local0)
                }
                And(PIRD, 0xf, PIRD)
                ShiftLeft(Local1, 0x4, Local1)
                Or(PIRD, Local1, PIRD)
            }

This assumes the resource passed to it is a normal IRQ resource, and cannot 
cope with extended ones. It only checks bytes 1&2 of the argument. For an 
extended argument, it would have to check bytes 5,6,7,8.

In linux, the call to acpi_pci_link_set() from acpi_pci_link_check() does not 
check the return status of the call. Otherwise this error would be detected.



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Located the problem with the VIA KT400 board

[hgfelger-9nAOAgdJVo4b1SvskN2V4Q]

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

Salut Andrew,
might it be a good idea to then step back to try creating an normal IRQ
resource if the extended one failed?

On Mon, 14 Jul 2003, Andrew de Quincey wrote:
> It does something like:
> if (irq <= 15) {
>   ... create an IRQ resource
> } else {
>   ... create an extended IRQ resource
> }
>....
> This assumes the resource passed to it is a normal IRQ resource, and cannot
> cope with extended ones. It only checks bytes 1&2 of the argument. For an
> extended argument, it would have to check bytes 5,6,7,8.
>
> In linux, the call to acpi_pci_link_set() from acpi_pci_link_check() does not
> check the return status of the call. Otherwise this error would be detected.

Cheers
  hartwig felger

Hartwig Felger informatics

- -- 
1024D/339FD693 Hartwig Felger <hgfelger-9nAOAgdJVo4b1SvskN2V4Q@public.gmane.org>
Key fingerprint = FB2F 3EE9 345A D55B 6FF2  0EC1 F5B0 684F 339F D693
For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Es0M9bBoTzOf1pMRAsLIAJ9SdnVbiHY9ScbvxplWivH0EAn8tQCePiLt
44cnbVelAe/Qax3A5TeJHrQ=
=nDFX
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Located the problem with the VIA KT400 board

[Andrew de Quincey]

On Monday 14 July 2003 16:32, hgfelger-9nAOAgdJVo4b1SvskN2V4Q@public.gmane.org wrote:
> Salut Andrew,
> might it be a good idea to then step back to try creating an normal IRQ
> resource if the extended one failed?

Yeah, I was thinking about that. However, the problem only occurs when you 
have IRQs > 15, and unfortunately, you cannot specify IRQs > 15 in normal IRQ 
descriptors.... they're a bitfield aren't they?

That particular KT400 BIOS only ever returns IRQs > 15 from the _PRS method 
for those link devices. So I've no idea how it could ever work.

I've really no idea what you should/can do in this case.




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1