linux-kernel - Re: 2.6.35-rc3 regression: IBM Maia system is unbootable [ACPI related?]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1277141166.10998.79.camel@mulgrave.site>
Date:	Mon, 21 Jun 2010 12:26:06 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org
Subject: Re: 2.6.35-rc3 regression: IBM Maia system is unbootable [ACPI
 related?]

On Mon, 2010-06-21 at 11:54 -0500, James Bottomley wrote:
> On Mon, 2010-06-21 at 11:33 -0500, James Bottomley wrote:
> > On Mon, 2010-06-21 at 18:18 +0200, Andi Kleen wrote:
> > > James Bottomley <James.Bottomley@...senPartnership.com> writes:
> > > 
> > > > The system in question has a set of root bridges, with the CD rom (which
> > > > is seen) being on bus 0 and the SCSI controller, which doesn't show up
> > > > being on bus 1 (with several other things on busses > 1).
> > > >
> > > > The system uses ACPI to detect the multiple bridges, so it seems that
> > > > this failure in 2.6.35-rc3:
> > > >
> > > > ACPI: Core revision 20100428
> > > > ACPI Error: Hardware did not enter ACPI mode (20100428/evxfevnt-103)
> > > > ACPI Warning: AcpiEnable failed (20100428/utxface-147)
> > > > ACPI: Unable to enable ACPI
> > > 
> > > That probably causes all the other problems. Without ACPI enabled
> > > modern systems generally do not work.
> > > 
> > > Just guessing, but maybe try to revert
> > > 
> > > b430acbd7c4b919886fa7fd92eeb7a695f1940d3
> > > 
> > > That was the last change in this area.
> > 
> > I can confirm that reverting this over a vanilla 2.6.35-rc3 fixes my
> > boot problem.
> 
> Andi asked for the timings with the commit reverted, so here they are
> (from ACPI version print to PCI root busses found):
> 
> [    0.084086] ACPI: Core revision 20100428
> [    0.119779] Setting APIC routing to physical flat
> [    0.124259] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> [    0.128000] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> [    0.128000] ...trying to set up timer (IRQ0) through the 8259A ...
> [    0.128000] ..... (found apic 0 pin 2) ...
> [    0.128000] ....... failed.
> [    0.128000] ...trying to set up timer as Virtual Wire IRQ...
> [    0.169681] ..... works.
> [    0.172005] CPU0: Intel(R) Xeon(TM) MP CPU 3.16GHz stepping 01
> [    0.188000] lockdep: fixing up alternatives.
> [    0.188133] Booting Node   0, Processors  #1 Ok.
> [    0.288089] Brought up 2 CPUs
> [    0.292006] Total of 2 processors activated (12676.86 BogoMIPS).
> [    0.300923] khelper used greatest stack depth: 5864 bytes left
> [    0.305017] khelper used greatest stack depth: 5176 bytes left
> [    0.325510] NET: Registered protocol family 16
> [    0.341322] ACPI: bus type pci registered
> [    0.344474] PCI: Using configuration type 1 for base access
> [    0.359165] bio: create slab <bio-0> at 0
> [    0.478153] ACPI: Interpreter enabled
> [    0.488006] ACPI: (supports S0 S5)
> [    0.497875] ACPI: Using IOAPIC for interrupt routing
> [    0.548145] ACPI: No dock devices found.
> [    0.552176] PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug
> [    0.556263] ACPI: PCI Root Bridge [VP00] (domain 0000 [bus 00])
> [    0.568051] ACPI: PCI Root Bridge [VP01] (domain 0000 [bus 01])
> [    0.576336] ACPI: PCI Root Bridge [VP02] (domain 0000 [bus 02-03])
> [    0.596889] ACPI: PCI Root Bridge [VP03] (domain 0000 [bus 04-05])
> [    0.605222] ACPI: PCI Root Bridge [VP04] (domain 0000 [bus 06-07])
> [    0.613530] ACPI: PCI Root Bridge [VP05] (domain 0000 [bus 08-09])
> [    0.617658] ACPI: PCI Root Bridge [VP06] (domain 0000 [bus 0a-0b])
> [    0.621672] ACPI: PCI Root Bridge [VP07] (domain 0000 [bus 0c-0d])
> [    0.625948] HEST: Table is not found!

Another update: It's clear the problem is the new expectation that the
hardware sets ACPI mode instantly.  I applied the following patch on my
system to see how long it actually takes.  I see a single loop:

[    0.084087] ACPI: Core revision 20100428
[    0.119720] ACPI Error: Hardware did not enter ACPI mode, retry = 0 (20100428/evxfevnt-104)
[    0.128240] Setting APIC routing to physical flat

So it needs a delay of about 1ms (or one retry).

James

---
diff --git a/drivers/acpi/acpica/evxfevnt.c b/drivers/acpi/acpica/evxfevnt.c
index d5a5efc..bace473 100644
--- a/drivers/acpi/acpica/evxfevnt.c
+++ b/drivers/acpi/acpica/evxfevnt.c
@@ -70,6 +70,7 @@ acpi_ev_get_gpe_device(struct acpi_gpe_xrupt_info *gpe_xrupt_info,
 acpi_status acpi_enable(void)
 {
 	acpi_status status;
+	int retry = 0;
 
 	ACPI_FUNCTION_TRACE(acpi_enable);
 
@@ -98,6 +99,11 @@ acpi_status acpi_enable(void)
 
 	/* Sanity check that transition succeeded */
 
+	while (acpi_hw_get_mode() != ACPI_SYS_MODE_ACPI && retry < 3000) {
+		ACPI_ERROR((AE_INFO,
+			    "Hardware did not enter ACPI mode, retry = %d", retry++));
+		acpi_os_stall(1000);
+	}
 	if (acpi_hw_get_mode() != ACPI_SYS_MODE_ACPI) {
 		ACPI_ERROR((AE_INFO,
 			    "Hardware did not enter ACPI mode"));


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/