login
Search
Gary, can you check this patch on your x3950? Thanks Yinghai [PATCH] x86: fix out of order of gsi found IBM x3950 will have problem after |commit b9c61b70075c87a8612624736faf4a2de5b1ed30 | | x86/pci: update pirq_enable_irq() to setup io apic routing The problem is that with the patch, the machine freezes when console=ttyS0,... kernel serial parameter is passed. It seem to freeze at DVD initialization and the whole problem seem to be DVD/pata related, but somehow exposed through the serial parameter. Such apic problems can expose really weird behavior.. <6>ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) <6>IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 <6>ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) <6>IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 <6>ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) <6>IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) it turns out that system have three io apic controller. but put boot ioapic routing in second one. and that gsi_base is not 0. it is using bunch of INT_SRC_OVR... recent changes 1. one set routing for first io apic controller 2. assume irq = gsi will break theat system. so try to remap those gsi, need to ...
Subject: [PATCH -v2] x86: fix out of order of gsi found IBM x3950 will have problem after |commit b9c61b70075c87a8612624736faf4a2de5b1ed30 | | x86/pci: update pirq_enable_irq() to setup io apic routing The problem is that with the patch, the machine freezes when console=ttyS0,... kernel serial parameter is passed. It seem to freeze at DVD initialization and the whole problem seem to be DVD/pata related, but somehow exposed through the serial parameter. Such apic problems can expose really weird behavior.. <6>ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) <6>IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 <6>ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) <6>IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 <6>ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) <6>IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) it turns out that system have three io apic controller. but put boot ioapic routing in second one. and that gsi_base is not 0. it is using bunch of INT_SRC_OVR... recent changes 1. one set routing for first io apic controller 2. assume irq = gsi will break theat system. so try to remap those gsi, need to seperate boot_ioapic_id detection out of enable_IO_APIC and ...
This looks like it is doing something very different from implementing a one irq at a time override, and after the nasties remapping gsi have caused in the past I find this function very scary. Eric --
found IBM x3950 will have problem after |commit b9c61b70075c87a8612624736faf4a2de5b1ed30 | | x86/pci: update pirq_enable_irq() to setup io apic routing The problem is that with the patch, the machine freezes when console=ttyS0,... kernel serial parameter is passed. It seem to freeze at DVD initialization and the whole problem seem to be DVD/pata related, but somehow exposed through the serial parameter. Such apic problems can expose really weird behavior.. <6>ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) <6>IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 <6>ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) <6>IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 <6>ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) <6>IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) it turns out that system have three io apic controller. but put boot ioapic routing in second one. and that gsi_base is not 0. it is using bunch of INT_SRC_OVR... recent changes 1. one set routing for first io apic controller 2. assume irq = gsi will break theat system. so try to remap those gsi, need to seperate boot_ioapic_id detection out of enable_IO_APIC and call them early. introduce boot_ioapic_id, and ...
Commit-ID: ca8c764cb39bf6cade71933b38e8c830eb8b73c6 Gitweb: http://git.kernel.org/tip/ca8c764cb39bf6cade71933b38e8c830eb8b73c6 Author: Yinghai Lu <yinghai@kernel.org> AuthorDate: Fri, 26 Feb 2010 11:30:30 -0800 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Sat, 27 Feb 2010 12:54:16 +0100 x86: Fix out of order gsi - have the right boot_ioapic_idx Iranna D Ankad reported that IBM x3950 systems have boot problems after this commit: | | commit b9c61b70075c87a8612624736faf4a2de5b1ed30 | | x86/pci: update pirq_enable_irq() to setup io apic routing | The problem is that with the patch, the machine freezes when console=ttyS0,... kernel serial parameter is passed. It seem to freeze at DVD initialization and the whole problem seem to be DVD/pata related, but somehow exposed through the serial parameter. Such apic problems can expose really weird behavior: ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) It turns out that ...
found IBM x3950 will have problem after |commit b9c61b70075c87a8612624736faf4a2de5b1ed30 | | x86/pci: update pirq_enable_irq() to setup io apic routing The problem is that with the patch, the machine freezes when console=ttyS0,... kernel serial parameter is passed. It seem to freeze at DVD initialization and the whole problem seem to be DVD/pata related, but somehow exposed through the serial parameter. Such apic problems can expose really weird behavior.. <6>ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) <6>IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 <6>ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) <6>IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 <6>ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) <6>IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) it turns out that system have three io apic controller. but put boot ioapic routing in second one. and that gsi_base is not 0. it is using bunch of INT_SRC_OVR... recent changes 1. one set routing for first io apic controller 2. assume irq = gsi will break theat system. so try to remap those gsi, need to seperate boot_ioapic_id detection out of enable_IO_APIC and call them early. introduce boot_ioapic_id, and ...
Commit-ID: 519d637a93116ffbcd50e9e3f2591f41584f372c Gitweb: http://git.kernel.org/tip/519d637a93116ffbcd50e9e3f2591f41584f372c Author: Yinghai Lu <yinghai@kernel.org> AuthorDate: Fri, 26 Feb 2010 11:31:14 -0800 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Sat, 27 Feb 2010 12:54:17 +0100 x86: Fix out of order gsi -- add remap_ioapic_gsi_to_irq() Iranna D Ankad found (and bisected) that IBM x3950 will have boot problems after: | | commit b9c61b70075c87a8612624736faf4a2de5b1ed30 | | x86/pci: update pirq_enable_irq() to setup io apic routing | As explained in the previous patch ("x86: Fix out of order gsi - have the right boot_ioapic_idx"), try to remap those gsis, we need to seperate boot_ioapic_id detection out of enable_IO_APIC and call them early. This patch adds remap_ioapic_gsi() and fixes the regression. Reported-by: Iranna D Ankad <iranna.ankad@in.ibm.com> Bisected-by: Iranna D Ankad <iranna.ankad@in.ibm.com> Tested-by: Gary Hade <garyhade@us.ibm.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Thomas Renninger <trenn@suse.de> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Cc: len.brown@intel.com Cc: <stable@kernel.org> # .33.x LKML-Reference: <4B882182.4030205@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- arch/x86/include/asm/io_apic.h | 2 +- arch/x86/include/asm/mpspec.h | 2 + arch/x86/kernel/acpi/boot.c | 63 ++++++++++++++++++++++++++++++++++----- arch/x86/kernel/apic/io_apic.c | 22 +++++++++----- drivers/pnp/pnpacpi/rsparser.c | 8 +++++ 5 files changed, 80 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h index b16c075..98458c7 100644 --- a/arch/x86/include/asm/io_apic.h +++ b/arch/x86/include/asm/io_apic.h @@ -161,7 +161,7 @@ extern int io_apic_get_redir_entries(int ioapic); struct io_apic_irq_attr; extern int io_apic_set_pci_routing(struct device *dev, int irq, struct ...
Causes: arch/x86/kernel/apic/io_apic.c:1042: error: implicit declaration of function ?remap_ioapic_gsi_to_irq? Please send delta fix. Thanks, Ingo --
please check
[PATCH] x86: fix warning with remap_ioapic_gsi_to_irq when !CONFIG_ACPI
Ingo found:
| x86: Fix out of order gsi -- add remap_ioapic_gsi_to_irq()
cause:
arch/x86/kernel/apic/io_apic.c:1042: error: implicit declaration of function ?remap_ioapic_gsi_to_irq?
actually when !CONFIG_ACPI, we have
#define acpi_ioapic 0
somehow we still get warning for
#if (!0) {
...
} else {
...
remap_ioapic_gsi_to_irq...
}
gcc bug?
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
arch/x86/include/asm/mpspec.h | 8 ++++++++
1 file changed, 8 insertions(+)
Index: linux-2.6/arch/x86/include/asm/mpspec.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/mpspec.h
+++ linux-2.6/arch/x86/include/asm/mpspec.h
@@ -116,6 +116,14 @@ static inline int acpi_probe_gsi(void)
{
return 0;
}
+static inline int remap_ioapic_gsi_to_irq(int ioapic, u32 gsi)
+{
+ return gsi;
+}
+static inline int remap_ioapic_irq_to_gsi(int irq)
+{
+ return irq;
+}
#endif /* CONFIG_ACPI */
#define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_APICS)
--
You're confusing #if and if ( ) { .. }.
Inside an if () { ... } clause the contents still needs to be correct,
even if it will get optimized out.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
I am certain I have said this before but the entire concept of irq != gsi is broken. We used to have code that did this and it was a non-ending source of problems that we finally removed after we pushed up the limit on the number of irqs. We already have the irq_2_pin list which allows for arbitrary mappings between irqs and the ioapics and pins. So there should be no problem mapping irq to gsi and assigning irqs to arbitrary ioapic pins. I have yet to see something that even purports to be an explanation of why our handling of acpi int_src_overrides is broken and why it needs the mess that is a remapper. I don't doubt YHs changes fix something but this feels like a direction that trades off one bug for another instead of actually fixing the code. It does look like we have weird old hard codes in some of the irq_2_pin and pin_2_irq paths that YH is touching, and it may make sense to introduce a concept of ioapic pin index. The touching of drivers/pnp/pnpacpi/rsparser.c feels like just the tip of the iceberg in dealing with weird bugs if we continue down this path. Eric --
the x3950 has strange gsi base ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 and BIOS using INT_SRC_OVR to map back gsi 3 - 18 to irq 0 - 15 ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) if we dont have this patch to do the remap (swap some mapping between ioapic), and only assume irq = gsi, the irq from first ioapic controller will be blocked. so far this patch only affect (fix ) x3950. all other platform will all have boot_ioapic_idx's gsi_base == 0, the function will just still return gsi. other solution will ask IBM to fix their bios, so we can get ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[36]) IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 36-38 ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[0]) IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 0-35 ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 then they don't need append that bunch of OVR. Yinghai --
Bah. I was hoping Len Brown would have looked at this earlier.
I just read through the relevant sections of the ACPI spec
1.0, 2.0 and 3.0 so I can understand what is really going on.
What the x3950 firmware does is stupid, and probably needs to be
changed but it is in spec.
I see two issues here.
- You broke x3950 by only initializing the first ioapic.
We should be able to fix that by having setup_IO_APIC_irqs
loop through all of the irqs and setup setup any irq with
pin_2_irq < 16. It is fragile and out of spec to assume only
one ioapic will have all of the isa irqs connected to it.
Plus extending your loop should be simpler and less intrusive
patch than what you have posted.
Although I suspect your patch to find the boot_ioapic_idx is
good enough for now.
- The fact that our current code makes 3 gsis/irqs on the x3950 unusable.
This is the justification for the remapping and unless this is
also a regression I don't think we should fix this in the
current merge window.
acpi guarantees there will be a 1 to 1 mapping between gsi's and
isa interrupts but it does not guarantee what that mapping will be.
acpi also specified that interrupt source overrides will only be
provided for the isa irqs.
linux irqs 0-15 must be the ISA irqs.
So to handle anything that is legitimate according to the acpi spec we
do need a mapping between gsi and irqs. Grrrr.
Something like:
/* By default isa irqs are identity mapped to gsis */
unsigned int isa_irq_to_gsi[16] = {
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
};
unsigned int gsi_to_irq(unsigned int gsi)
{
unsigned int irq = gsi + 16;
unsigned int i;
for (i = 0; i < 16; i++) {
if (isa_irq_to_gsi[i] == gsi)
irq = i;
}
return irq;
}
unsigned int irq_to_gsi(unsigned int irq)
{
unsigned int gsi;
if (irq < 16) {
gsi = isa_irq_to_gsi[irq];
} else {
gsi = irq - 16;
}
return gsi;
}
When we process the interrupt source overrides we just ...good, the mapping looks much clear. YH --
This is what I am thinking....
static void __init setup_IO_APIC_irqs(void)
{
int apic_id, pin, idx, irq;
int notcon = 0;
struct irq_desc *desc;
struct irq_cfg *cfg;
int node = cpu_to_node(boot_cpu_id);
apic_printk(APIC_VERBOSE, KERN_DEBUG "init IO_APIC IRQs\n");
for(apic_id = 0; apic_id < nr_ioapics; apic_id++) {
for (pin = 0; pin < nr_ioapic_registers[apic_id]; pin++) {
idx = find_irq_entry(apic_id, pin, mp_INT);
if (idx == -1) {
if (!notcon) {
notcon = 1;
apic_printk(APIC_VERBOSE,
KERN_DEBUG " %d-%d",
mp_ioapics[apic_id].apicid, pin);
} else
apic_printk(APIC_VERBOSE, " %d-%d",
mp_ioapics[apic_id].apicid, pin);
continue;
}
if (notcon) {
apic_printk(APIC_VERBOSE,
" (apicid-pin) not connected\n");
notcon = 0;
}
irq = pin_2_irq(idx, apic_id, pin);
+ if ((apic_id > 0) && (irq > 16))
+ continue;
/*
* Skip the timer IRQ if there's a quirk handler
* installed and if it returns 1:
*/
if (apic->multi_timer_check &&
apic->multi_timer_check(apic_id, irq))
continue;
desc = irq_to_desc_alloc_node(irq, node);
if (!desc) {
printk(KERN_INFO "can not get irq_desc for %d\n", irq);
continue;
}
cfg = desc->chip_data;
add_pin_to_irq_node(cfg, node, apic_id, pin);
/*
* don't mark it in pin_programmed, so later acpi could
* set it correctly when irq < 16
*/
setup_IO_APIC_irq(apic_id, pin, irq, desc,
irq_trigger(idx), irq_polarity(idx));
}
}
if (notcon)
apic_printk(APIC_VERBOSE,
" (apicid-pin) not connected\n");
Thanks. This code is just too convoluted to introduce many more
hacks and not have it fall over.
Eric
--
found IBM x3950 will have problem after |commit b9c61b70075c87a8612624736faf4a2de5b1ed30 | | x86/pci: update pirq_enable_irq() to setup io apic routing The problem is that with the patch, the machine freezes when console=ttyS0,... kernel serial parameter is passed. It seem to freeze at DVD initialization and the whole problem seem to be DVD/pata related, but somehow exposed through the serial parameter. Such apic problems can expose really weird behavior.. <6>ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) <6>IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 <6>ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) <6>IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 <6>ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) <6>IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) it turns out that system have three io apic controller. but put boot ioapic routing in second one. and that gsi_base is not 0. it is using bunch of INT_SRC_OVR... recent changes 1. one set routing for first io apic controller 2. assume irq = gsi will break theat system. so try to remap those gsi, need to seperate boot_ioapic_id detection out of enable_IO_APIC and call them early. introduce boot_ioapic_id, and ...
found IBM x3950 will have problem after |commit b9c61b70075c87a8612624736faf4a2de5b1ed30 | | x86/pci: update pirq_enable_irq() to setup io apic routing The problem is that with the patch, the machine freezes when console=ttyS0,... kernel serial parameter is passed. It seem to freeze at DVD initialization and the whole problem seem to be DVD/pata related, but somehow exposed through the serial parameter. Such apic problems can expose really weird behavior.. <6>ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) <6>IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 <6>ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) <6>IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 <6>ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) <6>IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) it turns out that system have three io apic controller. but put boot ioapic routing in second one. and that gsi_base is not 0. it is using bunch of INT_SRC_OVR... recent changes 1. one set routing for first io apic controller 2. assume irq = gsi will break theat system. so try to remap those gsi, need to seperate boot_ioapic_id detection out of enable_IO_APIC and call them early. introduce boot_ioapic_id, and ...
From: Eric W. Biederman <ebiederm@xmission.com> found IBM x3950 will have problem after |commit b9c61b70075c87a8612624736faf4a2de5b1ed30 | | x86/pci: update pirq_enable_irq() to setup io apic routing The problem is that with the patch, the machine freezes when console=ttyS0,... kernel serial parameter is passed. It seem to freeze at DVD initialization and the whole problem seem to be DVD/pata related, but somehow exposed through the serial parameter. Such apic problems can expose really weird behavior.. <6>ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) <6>IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 <6>ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) <6>IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 <6>ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) <6>IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) it turns out that system have three io apic controller. but put boot ioapic routing in second one. and that gsi_base is not 0. it is using bunch of INT_SRC_OVR... recent changes 1. one set routing for first io apic controller 2. assume irq = gsi will break theat system. so try to remap those gsi, need to seperate boot_ioapic_id detection out of enable_IO_APIC and call ...
Have you seen the commit notifications i sent for the v8 patches: Commit-ID: ca8c764cb39bf6cade71933b38e8c830eb8b73c6 Commit-ID: 519d637a93116ffbcd50e9e3f2591f41584f372c Those include a much improved changelogs - please adopt those. (and preferably send deltas against tip:tmp.x86/apic.) Thanks, Ingo --
From: Eric W. Biederman <ebiederm@xmission.com> Iranna D Ankad reported that IBM x3950 systems have boot problems after this commit: | | commit b9c61b70075c87a8612624736faf4a2de5b1ed30 | | x86/pci: update pirq_enable_irq() to setup io apic routing | The problem is that with the patch, the machine freezes when console=ttyS0,... kernel serial parameter is passed. It seem to freeze at DVD initialization and the whole problem seem to be DVD/pata related, but somehow exposed through the serial parameter. Such apic problems can expose really weird behavior: ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) It turns out that the system has three io apic controllers, but boot ioapic routing is in the second one, and that gsi_base is not 0 - it is using a bunch of INT_SRC_OVR... So these recent changes: 1. one set routing for first io apic controller 2. assume irq = gsi ... will break that system. So try to remap those gsis, ...
Commit-ID: fad539956c9e69749a03f7817d22d1bab87657bf Gitweb: http://git.kernel.org/tip/fad539956c9e69749a03f7817d22d1bab87657bf Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Sun, 28 Feb 2010 01:06:34 -0800 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Sun, 28 Feb 2010 10:33:25 +0100 x86: Fix out of order of gsi Iranna D Ankad reported that IBM x3950 systems have boot problems after this commit: | | commit b9c61b70075c87a8612624736faf4a2de5b1ed30 | | x86/pci: update pirq_enable_irq() to setup io apic routing | The problem is that with the patch, the machine freezes when console=ttyS0,... kernel serial parameter is passed. It seem to freeze at DVD initialization and the whole problem seem to be DVD/pata related, but somehow exposed through the serial parameter. Such apic problems can expose really weird behavior: ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0]) IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2 ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3]) IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38 ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39]) IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74 ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl) It turns out that the system has three ...
please drop those two. will send v12 to you. Thanks Yinghai --
Eh, not sure, but could it be Ingo forgot the 2nd
part of v12?
In linux-2.6-tip I see:
commit fad539956c9e69749a03f7817d22d1bab87657bf
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Sun Feb 28 01:06:34 2010 -0800
x86: Fix out of order of gsi
which equals:
[PATCH -v12 1/2] x86: fix out of order of gsi -- partial
but I cannot see:
[PATCH -v12 2/2] x86: fix out of order of gsi - full
Also this machine booted/worked fine up to 2.6.30.
Any chance this will get addressed in stable@ kernel(s)?
Thanks,
Thomas
--
patch 1/2: should be with stable@ #.32 and #.33 patch 2/2: could be only with 2.6.34 or 2.6.35 Thanks Yinghai --
Iranna D Ankad reported that IBM x3950 systems have boot problems
after this commit:
|
| commit b9c61b70075c87a8612624736faf4a2de5b1ed30
|
| x86/pci: update pirq_enable_irq() to setup io apic routing
|
As explained in the previous patch ("x86: Fix out of order gsi - partial)
try to remap those gsis
This patch adds boot_ioapic_idx and gsi_to_irq/irq_to_gsi
Reported-by: Iranna D Ankad <iranna.ankad@in.ibm.com>
Bisected-by: Iranna D Ankad <iranna.ankad@in.ibm.com>
Tested-by: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: len.brown@intel.com
---
arch/x86/include/asm/io_apic.h | 2
arch/x86/include/asm/mpspec.h | 3 +
arch/x86/kernel/acpi/boot.c | 28 +++++++----
arch/x86/kernel/apic/io_apic.c | 104 +++++++++++++++++++++++++++++++++--------
drivers/pnp/pnpacpi/rsparser.c | 8 +++
5 files changed, 114 insertions(+), 31 deletions(-)
Index: linux-2.6/arch/x86/include/asm/io_apic.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/io_apic.h
+++ linux-2.6/arch/x86/include/asm/io_apic.h
@@ -160,7 +160,7 @@ extern int io_apic_get_redir_entries(int
struct io_apic_irq_attr;
extern int io_apic_set_pci_routing(struct device *dev, int irq,
struct io_apic_irq_attr *irq_attr);
-void setup_IO_APIC_irq_extra(u32 gsi);
+void setup_IO_APIC_irq_extra(u32 gsi, unsigned int *irq);
extern int (*ioapic_renumber_irq)(int ioapic, int irq);
extern void ioapic_init_mappings(void);
extern void ioapic_insert_resources(void);
Index: linux-2.6/arch/x86/include/asm/mpspec.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/mpspec.h
+++ linux-2.6/arch/x86/include/asm/mpspec.h
@@ -97,6 +97,9 @@ static inline void early_reserve_e820_mp
#endif
void __cpuinit ...This should really live in arch/x86/kernel/acpi/boot.c or similar as it has everything to do with acpi and gsis and nothing to do with the ioapics. Not this merge window, but ultimately we want a fixed value of 16 for gsi_delta, and we want to always use it. This has a greater chance of breaking things but it will ensure in the long run that we flush out I would like to understand this better. I suspect the actual problem is that we are getting passed bus_irq instead of gsi from acpi. If we are getting passed the bus_irq than doing this just for x3950 is wrong. I really dislike having special cases for a specific motherboard. Both because they are hard to maintain (as quickly no one has that board) and because may times they are a symptom of a bug elsewhere in the code Eric --
I just realized that we already have this function in arch/x86/kernel/acpi/boot.c and arch/ia64/kernel/acpi.c it is called: acpi_gsi_to_irq() We still need this implementation but it will get really confusing if we have two functions with the same name trying to do the same job. I am relieved to see this because this should mean we shouldn't have many hard fixed assumptions that irq == gsi. This does mean though that your patch has a real bug in it because you have not updated acpi_gsi_to_irq. --
please check
i still like to see gsi_delta to be 0 for sane system.
Thanks
Yinghai
Subject: [PATCH -v13] x86: fix out of order of gsi - full
Iranna D Ankad reported that IBM x3950 systems have boot problems
after this commit:
|
| commit b9c61b70075c87a8612624736faf4a2de5b1ed30
|
| x86/pci: update pirq_enable_irq() to setup io apic routing
|
ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0])
IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2
ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3])
IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38
ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39])
IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74
As explained in the previous patch ("x86: Fix out of order gsi)
need to remap those gsis
This patch adds boot_ioapic_idx and gsi_to_irq/irq_to_gsi
So we could make sure for those kind of system will have
irq: 0 - 15 for legacy irq
irq: 16 after will be gsi + 16
-v13: move gsi_to_irq/irq_to_gsi to acpi/boot.c
Reported-by: Iranna D Ankad <iranna.ankad@in.ibm.com>
Bisected-by: Iranna D Ankad <iranna.ankad@in.ibm.com>
Tested-by: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: len.brown@intel.com
---
arch/x86/include/asm/io_apic.h | 2 -
arch/x86/include/asm/mpspec.h | 12 +++++++
arch/x86/kernel/acpi/boot.c | 64 +++++++++++++++++++++++++++++++------
arch/x86/kernel/apic/io_apic.c | 70 +++++++++++++++++++++++++++++------------
drivers/pnp/pnpacpi/rsparser.c | 4 ++
5 files changed, 121 insertions(+), 31 deletions(-)
Index: linux-2.6/arch/x86/include/asm/io_apic.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/io_apic.h
+++ linux-2.6/arch/x86/include/asm/io_apic.h
@@ ...It isn't just IBM. Asus P2B-D (PIIX4) and SuperMicro X8DAL (possibly) seem to have the same issue. (http://lists.xensource.com/archives/html/xen-devel/2010-02/msg00715.html) and (http://lists.xensource.com/archives/html/xen-devel/2010-02/msg01239.html) --
looks it is different... their ioapic is sane... ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level) --
I can't find the reference to those boards in the email you quoted. Xen does strange and very different things with it's irqs so it is unlikely to be the same issue. Eric --
Might have to hit the past button a couple of times. Anyway, here is the first description of the problem: http://lists.xensource.com/archives/html/xen-devel/2010-01/msg01049.html I think I am confusing the patches. Adding in this patch: [PATCH 01/35] x86: fix sci on ioapic 1 which was posted by Yinghai Lu on Feb 9th fixed the issue with the ASUS board. and the discussion here is for a different patch, so I think I am raising unnecessary noise here - sorry about that. --
Yinghai, Wouldn't it be better to have the person that reported the problem (Iranna) do that? Gary -- Gary Hade System x Enablement IBM Linux Technology Center 503-578-4503 IBM T/L: 775-4503 garyhade@us.ibm.com http://www.ibm.com/linux/ltc --
