Description of problem:
Crash on boot after 0.8 seconds
Version-Release number of selected component (if applicable):
Upgrade to this kernel, reboot
Steps to Reproduce:
The same server works fine with kernels 2.6.38 and older. It runs Pentium 4 at 2.8 GHz on an Intel D865PERL motherboard. Photo of the crash screen is attached, since data can't be captured otherwise. See also bug 729315 about crashes using kernel 2.6.40-4.fc15.i686.PAE
Created attachment 523709 [details]
Photo of crash screen
Photo of crash screen 0.8 seconds into the boot process.
acpi_processor_power_init() calls acpi_processor_get_power_info(), which eventually jumps to 0xffffff00
Can you try to get more information?
1. Install kernel-debug package
2. Boot with acpi.debug_layer=0x20000000 acpi.debug_level=0x7
3. See if any additional messages print before the oops
I've got the same problem on an Intel S875WP1 motherboard + Pentium 4 2,8 GHz.
I tried both kernel-PAEdebug and kernel-debug. With kernel-PAEdebug, too much output scrolls off the screen to give me anything useful. With kernel-debug, the kernel crash (about 3 seconds into the boot process) seems to occur in acpi_processor_power_init(). Traceback shows acpi_processor_add, acpi_device_probe, acpi_bus_register_device, acpi_processor_init, and acpi_pci_slot_init, interspersed with non-acpi functions.
This is a Pentium 4 2.8GHz SINGLE core processor with hyper threading only. Is it possible that acpi_processor_power_init is getting confused about the core count?
The backtrace in comment #1 looks very similar to the backtrace in the 'test 3' attachment in bug 730007. Both machines have P4 CPUs.
I've just upgraded to Fedora 16, using kernel 3.1.2-1, and while it also crashed on boot in its default setting, using "acpi=off" allows it to work.
The same server works fine with kernels 2.6.38 and older. It runs Pentium 4 at
2.8 GHz on an Intel D865PERL motherboard.
Again, something broke after 2.6.28, presumably related to ACPI handling on genuine Intel P4 systems, and it is still broken in 3.1.2, but at least I found a workaround: "acpi=off".
Matthew Garrett pointed me at a patch for a regression in ACPI yesterday. I've started a scratch build with this patch applied. Could those with an impacted machine please try this kernel when it finishes building and let us know the results?
My apologies, I pasted the wrong link to the scratch build. This is the one that should be tested:
*** This bug has been marked as a duplicate of bug 729315 ***