linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "STK" <stk@nerim.net>
To: "'Jos Hulzink'" <josh@stack.nl>,
	"'linux-kernel'" <linux-kernel@vger.kernel.org>
Cc: "'Zwane Mwaikambo'" <zwane@linuxpower.ca>
Subject: RE: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
Date: Mon, 12 May 2003 22:40:35 +0200	[thread overview]
Message-ID: <000c01c318c6$c0804990$0200a8c0@QUASARLAND> (raw)
In-Reply-To: <200305122135.53751.josh@stack.nl>

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/



  reply	other threads:[~2003-05-12 20:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-12 19:35 [RFC] How to fix MPS 1.4 + ACPI behaviour ? Jos Hulzink
2003-05-12 20:40 ` STK [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000c01c318c6$c0804990$0200a8c0@QUASARLAND' \
    --to=stk@nerim.net \
    --cc=josh@stack.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zwane@linuxpower.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).