2.6.35-rc3 regression: IBM Maia system is unbootable [ACPI related?]
in [Kernel]
|
Prev: [PATCH] X86: intel_ips, check for kzalloc properly
Next: [PATCH 8/8 v2]tuners:tuner-simple Fix warning: variable 'tun' set but not used
From: James Bottomley on 21 Jun 2010 12:10 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 Means that we can't detect any PCI bus other than 0 and thus the system won't boot. The full dmesgs for a successful (2.6.34) and failed (2.6.35-rc3) boot are below. James
From: James Bottomley on 21 Jun 2010 12:40 On Mon, 2010-06-21 at 18:18 +0200, Andi Kleen wrote: > James Bottomley <James.Bottomley(a)HansenPartnership.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. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 21 Jun 2010 13:00 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(a)HansenPartnership.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! James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 21 Jun 2010 13:30 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(a)HansenPartnership.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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Len Brown on 28 Jun 2010 20:20
James, Is this a production system with a production BIOS? BTW, "Instantly" here isn't actually instantly, it is "before the return from SMM". thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |