public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	hpa@zytor.com, garyhade@us.ibm.com, tglx@linutronix.de,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	iranna.ankad@in.ibm.com, suresh.b.siddha@intel.com,
	trenn@suse.de
Subject: [PATCH -v12 1/2] x86: fix out of order of gsi -- partial
Date: Sun, 28 Feb 2010 01:06:34 -0800	[thread overview]
Message-ID: <4B8A321A.1000008@kernel.org> (raw)
In-Reply-To: <20100228080941.GD14205@elte.hu>


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, need to seperate boot_ioapic_idx
detection out of enable_IO_APIC() and call them early.

So introduce boot_ioapic_idx, and remap_ioapic_gsi()...

 -v2: shift gsi with delta instead of gsi_base of boot_ioapic_idx

 -v3: double check with find_isa_irq_apic(0, mp_INT) to get right
      boot_ioapic_idx

 -v4: nr_legacy_irqs

 -v5: add print out for boot_ioapic_idx, and also make it could be
      applied for current kernel and previous kernel

 -v6: add bus_irq, in acpi_sci_ioapic_setup, so can get overwride
      for sci right mapping...

 -v7: looks like pnpacpi get irq instead of gsi, so need to revert
      them back...

 -v8: split into two patches

 -v9: according to Eric, use fixed 16 for shifting instead of remap

 -v10: still need to touch rsparser.c

 -v11: just revert back to way Eric suggest...
      anyway the ioapic in first ioapic is blocked by second...

 -v12: two patches, this one will add more loop but check apic_id and irq > 16

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/kernel/apic/io_apic.c |   28 ++++++++++------------------
 1 file changed, 10 insertions(+), 18 deletions(-)

Index: linux-2.6/arch/x86/kernel/apic/io_apic.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/apic/io_apic.c
+++ linux-2.6/arch/x86/kernel/apic/io_apic.c
@@ -1475,7 +1475,7 @@ static struct {
 
 static void __init setup_IO_APIC_irqs(void)
 {
-	int apic_id = 0, pin, idx, irq;
+	int apic_id, pin, idx, irq;
 	int notcon = 0;
 	struct irq_desc *desc;
 	struct irq_cfg *cfg;
@@ -1483,14 +1483,7 @@ static void __init setup_IO_APIC_irqs(vo
 
 	apic_printk(APIC_VERBOSE, KERN_DEBUG "init IO_APIC IRQs\n");
 
-#ifdef CONFIG_ACPI
-	if (!acpi_disabled && acpi_ioapic) {
-		apic_id = mp_find_ioapic(0);
-		if (apic_id < 0)
-			apic_id = 0;
-	}
-#endif
-
+	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) {
@@ -1512,6 +1505,9 @@ static void __init setup_IO_APIC_irqs(vo
 
 		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:
@@ -4105,27 +4101,23 @@ int acpi_get_override_irq(int bus_irq, i
 #ifdef CONFIG_SMP
 void __init setup_ioapic_dest(void)
 {
-	int pin, ioapic = 0, irq, irq_entry;
+	int pin, ioapic, irq, irq_entry;
 	struct irq_desc *desc;
 	const struct cpumask *mask;
 
 	if (skip_ioapic_setup == 1)
 		return;
 
-#ifdef CONFIG_ACPI
-	if (!acpi_disabled && acpi_ioapic) {
-		ioapic = mp_find_ioapic(0);
-		if (ioapic < 0)
-			ioapic = 0;
-	}
-#endif
-
+	for (ioapic = 0; ioapic < nr_ioapics; ioapic++)
 	for (pin = 0; pin < nr_ioapic_registers[ioapic]; pin++) {
 		irq_entry = find_irq_entry(ioapic, pin, mp_INT);
 		if (irq_entry == -1)
 			continue;
 		irq = pin_2_irq(irq_entry, ioapic, pin);
 
+		if ((ioapic > 0) && (irq > 16))
+			continue;
+
 		desc = irq_to_desc(irq);
 
 		/*

  parent reply	other threads:[~2010-02-28  9:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201002221108.42847.trenn@suse.de>
     [not found] ` <4B826CA6.7060007@kernel.org>
     [not found]   ` <201002221258.38506.trenn@suse.de>
2010-02-23  9:07     ` Other problem/regression with b9c61b70075c87a8612624736faf4a2de5b1ed30 Yinghai Lu
2010-02-23 18:40       ` Yinghai Lu
2010-02-23 20:17         ` Eric W. Biederman
2010-02-26 19:30         ` [PATCH -v8 1/2] x86: fix out of order of gsi - have right boot_ioapic_idx Yinghai Lu
2010-02-27 12:57           ` [tip:x86/apic] x86: Fix out of order gsi - have the " tip-bot for Yinghai Lu
2010-02-26 19:31         ` [PATCH -v8 2/2] x86: fix out of order of gsi -- add remap_ioapic_gsi_to_irq Yinghai Lu
2010-02-27 12:57           ` [tip:x86/apic] x86: Fix out of order gsi -- add remap_ioapic_gsi_to_irq() tip-bot for Yinghai Lu
2010-02-27 13:01             ` Ingo Molnar
2010-02-27 18:52               ` Yinghai Lu
2010-02-27 22:57                 ` H. Peter Anvin
2010-02-27 19:04               ` Eric W. Biederman
2010-02-27 19:40                 ` Yinghai Lu
2010-02-27 21:30                   ` Eric W. Biederman
2010-02-27 22:00                     ` Yinghai Lu
2010-02-27 22:18                       ` Eric W. Biederman
2010-02-27 22:58                         ` Yinghai Lu
2010-02-28  1:12                         ` [PATCH -v9] x86: fix out of order of gsi Yinghai Lu
2010-02-28  3:26                           ` [PATCH -v10] " Yinghai Lu
2010-02-28  3:47                         ` [PATCH -v11] x86: fix out of order of gsi -- partial Yinghai Lu
2010-02-28  8:09                           ` Ingo Molnar
2010-02-28  9:05                             ` Yinghai Lu
2010-03-01 14:40                               ` Thomas Renninger
2010-03-01 18:31                                 ` Yinghai Lu
2010-02-28  9:06                             ` Yinghai Lu [this message]
2010-02-28 19:51                               ` [tip:x86/apic] x86: Fix out of order of gsi tip-bot for Eric W. Biederman
2010-02-28  9:08                             ` [PATCH -v12 2/2] x86: fix out of order of gsi - full Yinghai Lu
2010-03-01 18:59                               ` Eric W. Biederman
2010-03-01 19:37                       ` [tip:x86/apic] x86: Fix out of order gsi -- add remap_ioapic_gsi_to_irq() Eric W. Biederman
2010-03-01 20:26                         ` Yinghai Lu
2010-03-01 16:46                     ` [LKML] " Konrad Rzeszutek Wilk
2010-03-01 18:37                       ` Yinghai Lu
2010-03-01 18:44                       ` Eric W. Biederman
2010-03-01 18:33                         ` [LKML] " Konrad Rzeszutek Wilk
2010-02-23 19:02       ` Other problem/regression with b9c61b70075c87a8612624736faf4a2de5b1ed30 Gary Hade

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=4B8A321A.1000008@kernel.org \
    --to=yinghai@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=garyhade@us.ibm.com \
    --cc=hpa@zytor.com \
    --cc=iranna.ankad@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=trenn@suse.de \
    /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