* [RFC] How to fix MPS 1.4 + ACPI behaviour ?
@ 2003-05-12 19:35 Jos Hulzink
2003-05-12 20:40 ` STK
2003-05-13 5:01 ` Jurriaan
0 siblings, 2 replies; 8+ messages in thread
From: Jos Hulzink @ 2003-05-12 19:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Zwane Mwaikambo
Hi,
(kernel: 2.5.69)
The conclusion of bug 699 is that some / all i386 SMP systems that use MPS 1.4
(and higher ? or all MPS versions ?), should boot with the "pci=noacpi"
parameter to prevent IRQ problems.
What exactly happens: The MPS 1.4 interpreter causes PCI IRQs to be remapped
to IRQ 16 and higher, which is the desired behaviour. The ACPI interpreter
comes in and finds no MADT table, for the Multiprocessor info is stored as
MPS table. No MADT table, so ACPI sets up the APIC in PIC mode (which I
wonder wether correct, but ok). As a result, the kernels pci_dev table tells
us that the IRQs have not been remapped (i.e. all values less than 16), while
the IRQs are actually mapped above 16.
All drivers of PCI cards claim the wrong IRQ line, and the end of story is
timeouts while waiting for an IRQ that never comes.
Remark: I think it is strange, that the kernel actually says: "ACPI: Using PIC
for interrupt routing", but it doesn't set up the PIC correctly (otherwise
the APIC rerouting table would be reset or something).
Now, my big question his: how to fix this. It is possible to have some code in
the kernel that does the same as "pci=noacpi", but what and where do I have
to do the check, with what condition ?
1) In the ACPI code, when MADT is not present ? Problem here is that the MPS
parser comes after the ACPI parser, so it isn't known yet that the MPS table
is present.
2) In the MPS parser ? As soon as an I/O APIC is detected by MPS, tell ACPI
not to touch the APIC ? You get acpi related code in non-acpi procedures
then...
3) Somewhere else ? How early in the kernel boot process should this option be
set ?
And an additional question: is "pci=noapic" the correct way to fix this ? It
runs fine here, but maybe we should only touch the IRQ related part ? If so,
how to do that ?
Please shoot... I found the problem, but this doesn't mean I understand the
kernel :)
Jos
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
2003-05-12 19:35 [RFC] How to fix MPS 1.4 + ACPI behaviour ? Jos Hulzink
@ 2003-05-12 20:40 ` STK
2003-05-12 20:50 ` Jos Hulzink
2003-05-13 5:01 ` Jurriaan
1 sibling, 1 reply; 8+ messages in thread
From: STK @ 2003-05-12 20:40 UTC (permalink / raw)
To: 'Jos Hulzink', 'linux-kernel'; +Cc: 'Zwane Mwaikambo'
Hi,
If no Multiple APIC Description Table (MADT) is described, in this case
the _PIC method can be used to tell the bios to return the right table
(PIC or APIC routing table).
In this case, if the MPS table describes matches the ACPI APIC table
(this is the case, because the ACPI APIC table is built from the MPS
table), you do not need to remap all IRQs.
I am really new in Kernel so I can't help you too much, but I can help
you on ACPI (I worked 5 years in Bios).
Hope it helps,
Yann
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Jos Hulzink
Sent: lundi 12 mai 2003 21:36
To: linux-kernel
Cc: Zwane Mwaikambo
Subject: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
Hi,
(kernel: 2.5.69)
The conclusion of bug 699 is that some / all i386 SMP systems that use
MPS 1.4
(and higher ? or all MPS versions ?), should boot with the "pci=noacpi"
parameter to prevent IRQ problems.
What exactly happens: The MPS 1.4 interpreter causes PCI IRQs to be
remapped
to IRQ 16 and higher, which is the desired behaviour. The ACPI
interpreter
comes in and finds no MADT table, for the Multiprocessor info is stored
as
MPS table. No MADT table, so ACPI sets up the APIC in PIC mode (which I
wonder wether correct, but ok). As a result, the kernels pci_dev table
tells
us that the IRQs have not been remapped (i.e. all values less than 16),
while
the IRQs are actually mapped above 16.
All drivers of PCI cards claim the wrong IRQ line, and the end of story
is
timeouts while waiting for an IRQ that never comes.
Remark: I think it is strange, that the kernel actually says: "ACPI:
Using PIC
for interrupt routing", but it doesn't set up the PIC correctly
(otherwise
the APIC rerouting table would be reset or something).
Now, my big question his: how to fix this. It is possible to have some
code in
the kernel that does the same as "pci=noacpi", but what and where do I
have
to do the check, with what condition ?
1) In the ACPI code, when MADT is not present ? Problem here is that the
MPS
parser comes after the ACPI parser, so it isn't known yet that the MPS
table
is present.
2) In the MPS parser ? As soon as an I/O APIC is detected by MPS, tell
ACPI
not to touch the APIC ? You get acpi related code in non-acpi procedures
then...
3) Somewhere else ? How early in the kernel boot process should this
option be
set ?
And an additional question: is "pci=noapic" the correct way to fix this
? It
runs fine here, but maybe we should only touch the IRQ related part ? If
so,
how to do that ?
Please shoot... I found the problem, but this doesn't mean I understand
the
kernel :)
Jos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in the body of a message to majordomo@vger.kernel.org More majordomo
info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
2003-05-12 20:40 ` STK
@ 2003-05-12 20:50 ` Jos Hulzink
2003-05-12 21:29 ` STK
0 siblings, 1 reply; 8+ messages in thread
From: Jos Hulzink @ 2003-05-12 20:50 UTC (permalink / raw)
To: STK, 'linux-kernel'; +Cc: 'Zwane Mwaikambo'
On Monday 12 May 2003 22:40, STK wrote:
> Hi,
>
> If no Multiple APIC Description Table (MADT) is described, in this case
> the _PIC method can be used to tell the bios to return the right table
> (PIC or APIC routing table).
>
> In this case, if the MPS table describes matches the ACPI APIC table
> (this is the case, because the ACPI APIC table is built from the MPS
> table), you do not need to remap all IRQs.
So, it's more or less a bug in the ACPI code that should do some things when
no MADT is dectected ? Or do I understand you wrong ?
Jos
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
2003-05-12 20:50 ` Jos Hulzink
@ 2003-05-12 21:29 ` STK
2003-05-13 7:50 ` Zwane Mwaikambo
2003-05-13 8:54 ` Jos Hulzink
0 siblings, 2 replies; 8+ messages in thread
From: STK @ 2003-05-12 21:29 UTC (permalink / raw)
To: 'Jos Hulzink', 'linux-kernel'; +Cc: 'Zwane Mwaikambo'
For me the linux kernel should invoke the _PIC method with the right
parameter.
Look at the specification Section
<< ================ Start ================
5.8.1 _PIC Method
The \_PIC optional method is to report to the BIOS the current interrupt
model used by the OS. This
control method returns nothing. The argument passed into the method
signifies the interrupt model OSPM
has chosen, PIC mode, APIC mode, or SAPIC mode. Notice that calling this
method is optional for OSPM.
If the method is never called, the BIOS must assume PIC mode. It is
important that the BIOS save the value
passed in by OSPM for later use during wake operations.
_PIC(x):
_PIC(0) => PIC Mode
_PIC(1) => APIC Mode
_PIC(2) => SAPIC Mode
_PIC(3-n) => Reserved
==================== End ====================>
==> No MADT table, so ACPI sets up the APIC in PIC mode (which I wonder
wether correct, but ok)
For me the kernel should invoke the _PIC method with the right
parameter, in this case the ACPI module will receive the right table
during the _PRT
Bios ASL code:
Method(_PRT)
{
If(\PICF) <== internal variable set by _PIC
{
==> Returning APIC Mode
Return(APIC)
}
Else
{
==> Returning PIC Mode
Return(PICM)
}
}
Regards,
Yann
-----Original Message-----
From: Jos Hulzink [mailto:josh@stack.nl]
Sent: lundi 12 mai 2003 22:51
To: STK; 'linux-kernel'
Cc: 'Zwane Mwaikambo'
Subject: Re: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
On Monday 12 May 2003 22:40, STK wrote:
> Hi,
>
> If no Multiple APIC Description Table (MADT) is described, in this
> case the _PIC method can be used to tell the bios to return the right
> table (PIC or APIC routing table).
>
> In this case, if the MPS table describes matches the ACPI APIC table
> (this is the case, because the ACPI APIC table is built from the MPS
> table), you do not need to remap all IRQs.
So, it's more or less a bug in the ACPI code that should do some things
when
no MADT is dectected ? Or do I understand you wrong ?
Jos
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
2003-05-12 21:29 ` STK
@ 2003-05-13 7:50 ` Zwane Mwaikambo
2003-05-13 8:54 ` Jos Hulzink
1 sibling, 0 replies; 8+ messages in thread
From: Zwane Mwaikambo @ 2003-05-13 7:50 UTC (permalink / raw)
To: STK; +Cc: 'Jos Hulzink', 'linux-kernel'
On Mon, 12 May 2003, STK wrote:
>
> For me the linux kernel should invoke the _PIC method with the right
> parameter.
>
Jos, if you switch to IOAPIC mode after failing you're going to have to
reprogram the IOAPIC again as specified in the mptables, setup_IOAPIC_irqs
does this. As well as do some other setup which ACPI let you get
past in arch/i386/kernel/mpparse.c. In a nutshell it'll get very convoluted
quickly.
Zwane
--
function.linuxpower.ca
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
2003-05-12 21:29 ` STK
2003-05-13 7:50 ` Zwane Mwaikambo
@ 2003-05-13 8:54 ` Jos Hulzink
1 sibling, 0 replies; 8+ messages in thread
From: Jos Hulzink @ 2003-05-13 8:54 UTC (permalink / raw)
To: STK, 'linux-kernel'; +Cc: 'Zwane Mwaikambo'
Hi,
As you can see below, current ACPI implementation concludes it has to use the
PIC, before it finds the PRT. No occurences of PRT in dmesg before this one.
vvvv
ACPI: Using PIC for interrupt routing
^^^^
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
vvvv
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
^^^^
Jos
On Monday 12 May 2003 23:29, STK wrote:
> For me the linux kernel should invoke the _PIC method with the right
> parameter.
>
> Look at the specification Section
>
> << ================ Start ================
> 5.8.1 _PIC Method
> The \_PIC optional method is to report to the BIOS the current interrupt
> model used by the OS. This
> control method returns nothing. The argument passed into the method
> signifies the interrupt model OSPM
> has chosen, PIC mode, APIC mode, or SAPIC mode. Notice that calling this
> method is optional for OSPM.
> If the method is never called, the BIOS must assume PIC mode. It is
> important that the BIOS save the value
> passed in by OSPM for later use during wake operations.
> _PIC(x):
> _PIC(0) => PIC Mode
> _PIC(1) => APIC Mode
> _PIC(2) => SAPIC Mode
> _PIC(3-n) => Reserved
>
> ==================== End ====================>
>
> ==> No MADT table, so ACPI sets up the APIC in PIC mode (which I wonder
> wether correct, but ok)
> For me the kernel should invoke the _PIC method with the right
> parameter, in this case the ACPI module will receive the right table
> during the _PRT
>
> Bios ASL code:
> Method(_PRT)
> {
> If(\PICF) <== internal variable set by _PIC
> {
> ==> Returning APIC Mode
> Return(APIC)
> }
> Else
> {
> ==> Returning PIC Mode
> Return(PICM)
> }
> }
>
> Regards,
>
> Yann
>
>
> -----Original Message-----
> From: Jos Hulzink [mailto:josh@stack.nl]
> Sent: lundi 12 mai 2003 22:51
> To: STK; 'linux-kernel'
> Cc: 'Zwane Mwaikambo'
> Subject: Re: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
>
> On Monday 12 May 2003 22:40, STK wrote:
> > Hi,
> >
> > If no Multiple APIC Description Table (MADT) is described, in this
> > case the _PIC method can be used to tell the bios to return the right
> > table (PIC or APIC routing table).
> >
> > In this case, if the MPS table describes matches the ACPI APIC table
> > (this is the case, because the ACPI APIC table is built from the MPS
> > table), you do not need to remap all IRQs.
>
> So, it's more or less a bug in the ACPI code that should do some things
> when
> no MADT is dectected ? Or do I understand you wrong ?
>
> Jos
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
2003-05-12 19:35 [RFC] How to fix MPS 1.4 + ACPI behaviour ? Jos Hulzink
2003-05-12 20:40 ` STK
@ 2003-05-13 5:01 ` Jurriaan
2003-05-13 7:15 ` Jos Hulzink
1 sibling, 1 reply; 8+ messages in thread
From: Jurriaan @ 2003-05-13 5:01 UTC (permalink / raw)
To: linux-kernel
From: Jos Hulzink <josh@stack.nl>
Date: Mon, May 12, 2003 at 09:35:53PM +0200
> Hi,
>
> (kernel: 2.5.69)
>
> The conclusion of bug 699 is that some / all i386 SMP systems that use MPS 1.4
> (and higher ? or all MPS versions ?), should boot with the "pci=noacpi"
> parameter to prevent IRQ problems.
>
Is this with or without IOAPIC? I got some problems with MPS 1.4, acpi
and the local ioapic on a uniprocessor system, see bugzilla 678. I think
it's a different problem, though.
Jurriaan
--
Evayne's smile turned sharply inward, although it remained on her face,
changed in tone and texture. "It loses none of its power," she whispered,
"and all of its romance."
Michelle West - Hunter's Death
Debian (Unstable) GNU/Linux 2.5.69 4112 bogomips load av: 0.64 0.16 0.05
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
2003-05-13 5:01 ` Jurriaan
@ 2003-05-13 7:15 ` Jos Hulzink
0 siblings, 0 replies; 8+ messages in thread
From: Jos Hulzink @ 2003-05-13 7:15 UTC (permalink / raw)
To: thunder7, linux-kernel
On Tuesday 13 May 2003 07:01, Jurriaan wrote:
> Is this with or without IOAPIC? I got some problems with MPS 1.4, acpi
> and the local ioapic on a uniprocessor system, see bugzilla 678. I think
> it's a different problem, though.
Your problem looks the same, though isn't, for your kernel finds a MADT:
ACPI: RSDP (v000 KT400 ) @ 0x000f74a0
ACPI: RSDT (v001 KT400 AWRDACPI 16944.11825) @ 0x3fff3000
ACPI: FADT (v001 KT400 AWRDACPI 16944.11825) @ 0x3fff3040
vvvvv
ACPI: MADT (v001 KT400 AWRDACPI 16944.11825) @ 0x3fff71c0
^^^^^
ACPI: DSDT (v001 KT400 AWRDACPI 00000.04096) @ 0x00000000
ACPI: BIOS passes blacklist
And ACPI uses the IOAPIC, as expected:
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
Unfortunately, we're talking two different bugs :(
Jos
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-05-13 8:37 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-12 19:35 [RFC] How to fix MPS 1.4 + ACPI behaviour ? Jos Hulzink
2003-05-12 20:40 ` STK
2003-05-12 20:50 ` Jos Hulzink
2003-05-12 21:29 ` STK
2003-05-13 7:50 ` Zwane Mwaikambo
2003-05-13 8:54 ` Jos Hulzink
2003-05-13 5:01 ` Jurriaan
2003-05-13 7:15 ` Jos Hulzink
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).