All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Josh Boyer <jwboyer@redhat.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
	Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
	yinghai@kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@fedoraproject.org, midgoon@gmail.com
Subject: Re: 3.2.1 Unable to reset IRR messages on boot
Date: Tue, 20 Mar 2012 05:40:48 -0400	[thread overview]
Message-ID: <20120320094048.GC20079@phenom.dumpdata.com> (raw)
In-Reply-To: <20120319193842.GA8123@phenom.dumpdata.com>

> > > > > Yes, it was helpful. Something like the appended patch should ignore the
> > > > > bogus io-apic entry all together. As I can't test this, can you or the
> > > > > reporter give the appended patch a try and ack please?
> > > > 
> > > > Hi Suresh,
> > > > 
> > > > Apologies for the delay.  The original reporter had to return the
> > > > machine he was using.  We've since had another report where this
> > > > happened and your patch below does indeed fix the issue.
> > > > 
> > > > I'd suggest pushing this soon.
> > > > 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=801501
> > > > 
> > > 
> > > Thanks Josh. Peter/Ingo, please queue the appended patch for -tip.
> > 
> > Hi Suresh,
> > 
> > Seems this patch and Xen don't get along very well.  See the bug link
> > below.  I've CC'd Konrad and hopefully he'll have some insight as to why
> > that might be.
> 
> Quick glance at the code tells me that the 'mp_register_ioapic' with the
> patch won't increment the gsi_top. That value (gsi_top) is used in
.. snip..
> So the IO_APIC is all 0xfff.. 

My "quick glance" was wrong. The reason we are dying is b/c the call
acpi_get_override_irq() is used, which returns the polarity and trigger for the
IRQs. But that function calls mp_find_ioapics to get the 'struct ioapic' structure
- which along with the mp_irq[x] is used to figure out the default values
and the polarity/trigger overrides. Since the mp_find_ioapics now returns -1
[b/c the IOAPIC is filled with 0xffffffff], the acpi_get_override_irq() stops
trying to lookup in the mp_irq[x] the proper INT_SRV_OVR and we can't install the
SCI interrupt.

Furthermore, we end up using that function in a loop to setup the sixteen legacy
interrupts:

    /* Pre-allocate legacy irqs */
480         for (irq = 0; irq < NR_IRQS_LEGACY; irq++) {
481                 int trigger, polarity;
482 
483                 if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
484                         continue;
485 
486                 xen_register_pirq(irq, -1 /* no GSI override */,
487                         trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE,
488                         true /* Map GSI to PIRQ */);


and since we get -1, we never end up setting any interrupts. 

Also the nr_ioapics ends up being zero, so we think we are running in legacy mode with XT-PIC
interrupts (ugh). By the time ACPI kicks in and wants to install the SCI interrupt
we blow up since we cannot get the proper irq_desc.

The interesting thing is that the same issue could be reproduced on baremetal
if the first IOAPIC had 0xfff all over it - and the call to acpi_get_override_irq()
done by the ACPI layer to setup the SCI would have triggered a similar failure.
But the baremetal failing case has the first IOAPIC with the INT_SRV_OVR with
valid values - it is just the second IOAPIC is busted.

Or if the second IOAPIC was busted and there was an INT_SRV_OVR for the second
APIC to handle the SCI.

I think there are three ways of fixing this:

 1). Revert Suresh's patch and look at just removing the "Unable to reset IRR" warning
    (perhaps by being conditional on running in kexec-env?).

 2). Make the Xen layer fake out an IOAPIC - so instead of 0xffffff, make sure to
     clear the three bits that Suresh' patch is testing for (Ewwwww, I don't actually
     like that - that stinks of a hack).

 3). Rework Suresh's patch - to only remove the IOAPIC entry if there is no
     INT_SRV_OVR that depend on it. I made a stab at it and here is draft patch, that
     looks to work on my boxes that have more than one IOAPIC and are booting under Xen:
     But I am not 100% confident about it so would appreciate somebody looking at it.

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 690d1cc..d92be91 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -170,6 +170,7 @@ extern u32 gsi_top;
 int mp_find_ioapic(u32 gsi);
 int mp_find_ioapic_pin(int ioapic, u32 gsi);
 void __init mp_register_ioapic(int id, u32 address, u32 gsi_base);
+void __init mp_erase_defective_ioapics(void);
 extern void __init pre_init_apic_IRQ0(void);
 
 extern void mp_save_irq(struct mpc_intsrc *m);
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index 9c7d95f..e886853 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -103,6 +103,7 @@ extern void mp_config_acpi_legacy_irqs(void);
 struct device;
 extern int mp_register_gsi(struct device *dev, u32 gsi, int edge_level,
 				 int active_high_low);
+extern void mp_erase_defective_ioapics(void);
 #endif /* CONFIG_ACPI */
 
 #define PHYSID_ARRAY_SIZE	BITS_TO_LONGS(MAX_LOCAL_APIC)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index c3a5b95..b5115e7 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1193,6 +1193,10 @@ static int __init acpi_parse_madt_ioapic_entries(void)
 	}
 
 	/*
+	 * Cleanup up invalid IOAPICs.
+	 */
+	mp_erase_defective_ioapics();
+	/*
 	 * If BIOS did not supply an INT_SRC_OVR for the SCI
 	 * pretend we got one so we can set the SCI flags.
 	 */
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 6d10a66..77f1e84 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3989,14 +3989,43 @@ static __init int bad_ioapic_register(int idx)
 	reg_02.raw = io_apic_read(idx, 2);
 
 	if (reg_00.raw == -1 && reg_01.raw == -1 && reg_02.raw == -1) {
-		pr_warn("I/O APIC 0x%x registers return all ones, skipping!\n",
-			mpc_ioapic_addr(idx));
 		return 1;
 	}
 
 	return 0;
 }
+bool __init no_gsi_override_for_ioapic(int idx)
+{
+	unsigned int gsi, i;
+	struct mp_ioapic_gsi *gsi_cfg;
+
+	gsi_cfg = mp_ioapic_gsi_routing(idx);
+	for (gsi = gsi_cfg->gsi_base; gsi < gsi_cfg->gsi_end; gsi++) {
+		unsigned int pin = mp_find_ioapic_pin(idx, gsi);
+		for (i = 0; i < mp_irq_entries; i++) {
+			if (mp_irqs[i].dstirq == pin &&
+				mp_irqs[i].dstapic == mpc_ioapic_id(idx))
+				return false;
+		}
+	}
+	return true;
+}
+void __init mp_erase_defective_ioapics(void)
+{
+	unsigned int idx = 0;
 
+	while (idx < nr_ioapics) {
+		if (bad_ioapic_register(idx) && no_gsi_override_for_ioapic(idx)) {
+			pr_warn("I/O APIC 0x%x registers return all ones, skipping!\n",
+				mpc_ioapic_addr(idx));
+			clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
+			memmove(&ioapics[idx], &(ioapics[idx+1]),
+				sizeof(struct ioapic) * (nr_ioapics - 1 - idx));
+			--nr_ioapics;
+		} else
+			idx++;
+	}
+}
 void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
 {
 	int idx = 0;
@@ -4014,11 +4043,6 @@ void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
 
 	set_fixmap_nocache(FIX_IO_APIC_BASE_0 + idx, address);
 
-	if (bad_ioapic_register(idx)) {
-		clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
-		return;
-	}
-
 	ioapics[idx].mp_config.apicid = io_apic_unique_id(id);
 	ioapics[idx].mp_config.apicver = io_apic_get_version(idx);
 

  reply	other threads:[~2012-03-20  9:45 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-25  0:04 3.2.1 Unable to reset IRR messages on boot Josh Boyer
2012-01-25  1:24 ` Suresh Siddha
2012-01-25 13:49   ` Josh Boyer
2012-01-25 22:04     ` Suresh Siddha
2012-01-25 23:15       ` Josh Boyer
2012-01-31 14:26         ` Josh Boyer
2012-02-01  8:00           ` Suresh Siddha
2012-03-12 13:24             ` Josh Boyer
2012-03-12 18:36               ` Suresh Siddha
2012-03-13  9:40                 ` [tip:x86/urgent] x86/ioapic: Add register level checks to detect bogus io-apic entries tip-bot for Suresh Siddha
2012-03-19 13:30                 ` 3.2.1 Unable to reset IRR messages on boot Josh Boyer
2012-03-19 19:38                   ` Konrad Rzeszutek Wilk
2012-03-20  9:40                     ` Konrad Rzeszutek Wilk [this message]
2012-03-20  9:59                       ` Ingo Molnar
2012-03-20 17:54                         ` Konrad Rzeszutek Wilk
2012-03-20 18:12                       ` Suresh Siddha
2012-03-20 18:58                         ` Konrad Rzeszutek Wilk
2012-03-20 20:05                           ` Suresh Siddha
2012-03-20 20:25                             ` Konrad Rzeszutek Wilk
2012-03-20 20:41                               ` Suresh Siddha
2012-03-20 20:48                                 ` Konrad Rzeszutek Wilk
2012-03-21  0:12                             ` Konrad Rzeszutek Wilk
2012-03-21  0:12                               ` [PATCH 1/3] x86: add io_apic_ops to allow interception Konrad Rzeszutek Wilk
2012-03-21  0:12                               ` [PATCH 2/3] x86/apic_ops: Replace apic_ops with x86_apic_ops Konrad Rzeszutek Wilk
2012-03-21  2:31                                 ` Yinghai Lu
2012-03-21 16:22                                   ` Konrad Rzeszutek Wilk
2012-03-21  0:12                               ` [PATCH 3/3] xen/x86: Implement x86_apic_ops Konrad Rzeszutek Wilk
2012-03-21  1:31                                 ` Suresh Siddha
2012-03-21 16:41                                   ` Konrad Rzeszutek Wilk
2012-03-21 19:01                                     ` Suresh Siddha
2012-03-21  1:42                               ` 3.2.1 Unable to reset IRR messages on boot Suresh Siddha
2012-03-22  2:58                                 ` 3.2.1 Unable to reset IRR messages on boot. [BZ#804347] Konrad Rzeszutek Wilk
2012-03-22  2:58                                   ` [PATCH 1/3] x86: add io_apic_ops to allow interception Konrad Rzeszutek Wilk
2012-03-28  9:23                                     ` Ingo Molnar
2012-03-28 17:37                                       ` Konrad Rzeszutek Wilk
2012-03-28 17:37                                         ` [PATCH 1/2] x86/apic: Replace io_apic_ops with x86_io_apic_ops Konrad Rzeszutek Wilk
2012-03-28 17:37                                         ` [PATCH 2/2] xen/x86: Implement x86_apic_ops Konrad Rzeszutek Wilk
2012-04-11  4:49                                           ` Lin Ming
2012-04-16 15:47                                             ` Konrad Rzeszutek Wilk
2012-04-17  0:52                                               ` Zhang, Xiantao
2012-04-18 21:03                                                 ` Konrad Rzeszutek Wilk
2012-04-20  9:33                                                   ` Lin Ming
2012-03-28  9:32                                     ` [tip:x86/urgent] x86/ioapic: Add io_apic_ops driver layer to allow interception tip-bot for Jeremy Fitzhardinge
2012-03-22  2:58                                   ` [PATCH 2/3] x86/apic_ops: Replace apic_ops with x86_apic_ops Konrad Rzeszutek Wilk
2012-03-23 12:24                                     ` Ingo Molnar
2012-03-26 14:44                                       ` Konrad Rzeszutek Wilk
2012-03-22  2:58                                   ` [PATCH 3/3] xen/x86: Implement x86_apic_ops Konrad Rzeszutek Wilk

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=20120320094048.GC20079@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=hpa@zytor.com \
    --cc=jwboyer@redhat.com \
    --cc=kernel-team@fedoraproject.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=midgoon@gmail.com \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=yinghai@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.