this is a kubuntu 32-bit system. in kubuntu 11.04, they were using the 2.6 kernel still, and the system was booting fine, up to the last kernel tried on that release: willy@Hamra:~$ uname -r 2.6.38-12-generic after upgrade to 11.10, ubuntu started using the 3.0 kernel, which won't boot on this board, unless ACPI=off was specified. but this, of course, removes all ACPI functionality, and disables hyper threading, effectively halving the processing power. kernels tried as shipped by ubuntu: willy@Hamra:~$ ls -1 /boot/vmlinuz-3.0* /boot/vmlinuz-3.0.0-13-generic /boot/vmlinuz-3.0.0-14-generic /boot/vmlinuz-3.0.0-15-generic /boot/vmlinuz-3.0.0-16-generic so i tried compiling a linux kernel from last month's 3.1 tree, to check if this is an ubuntu issue or a kernel issue. i used very close values to what i would normally use on my LinuxFromScratch and ended with same bug. then i brought the config of the 2.6.38-12-generic kernel provided by ubuntu, and used it as starting point for configuring the 3.1 kernel. i just ran the configuration program so it can remove obsolete options, and add necessary new ones, didnt modify anything myself, and compiled, again, same result, system won't boot. the stage of booting at which this issue happens is after these lines in the boot process: [ 0.285128] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 0.285432] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0 [ 0.285443] ACPI: Power Button [PWRB] [ 0.285571] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 [ 0.285579] ACPI: Power Button [PWRF] after the last PWRF line the system just hangs. no panic, no flashing keyboard LEDs, and no response at all. judging by the speed of fans, it doesnt seem the processor is stuck in an intensive infinite loop either. normally, on a 2.6 kernel, the lines following these are: [ 0.285849] ACPI: acpi_idle registered with cpuidle [ 0.287994] ERST: Table is not found! [ 0.288199] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 0.292073] isapnp: Scanning for PnP cards... hope this is enough info to be able to debug this issue. a launchpad bug report has been filed as well: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/883441 thanks in advance
Created attachment 72239 [details] dmesg output on 2.6
Created attachment 72240 [details] lspci -vvnn
Created attachment 72241 [details] dmidecode
what if you boot with idle=poll or idle=halt?
that was easy... either option works fine, and the system boots. thanks a lot for your help. any suggestions on which is preferable?
does booting with "intel_idle.max_cstate=0" have any effect? (I can't imagine it could, b/c acpi=off works, but lets confirm...) how about booting with "processor.max_cstate=1" "processor.max_cstate=2" "processor.max_cstate=3" etc? For the last one that works, please show the output from grep . /sys/devices/system/cpu/cpu0/cpuidle/*/*
just to be clear, you want me to try these without the "idle=" parameter? if that's the case, none worked, they all resulted in the same hang, on the same place during the boot process. the only difference is an additional line stating the CPU c-state got limited to X, etc..
hmm, I guess "idle=nomwait" also works for you, right? please attach the output of acpidump for you machine.
actually no, "idle=nomwait" also results in a hang, so far, only "idle=halt" and "idle=poll" are booting the system. i just booted with idle=halt, and ran acpidump, the output is in the next attachment.
Created attachment 72373 [details] sudo acpidump
Created attachment 72490 [details] 001-ACPICA-Fix-regression-in-FADT-revision-checks.patch please test the attached patch which fixes https://bugzilla.redhat.com/show_bug.cgi?id=727865
sorry for this very late reply, it does actually solve the bug. i tried with a trunk kernel pulled from git, 3 weeks ago. compiled it without patch, to make sure bug existed in that kernel, then compiled it again with patch, and lo and behold, bug gone :)
good. Bug closed
A patch referencing this bug report has been merged in Linux v3.4-rc1: commit 3e80acd1af40fcd91a200b0416a7616b20c5d647 Author: Julian Anastasov <ja@ssi.bg> Date: Thu Feb 23 22:40:43 2012 +0200 ACPICA: Fix regression in FADT revision checks
Hello, this is my first post in this tracking system. Sadly I have to say that the patch above does NOT fix the problem for me. I tried several kernels, but no one of the 3.x branch works, patched or unpatched, unless acpi=off . Here's the kernels I tried: - kernel 2.6.32 --> OK - kernel 3.0.0 patched/unpatched --> ERROR - kernel vanilla 3.2 patched/unpatched --> ERROR There is no way to boot with a kernel 3.x unless acpi=off. Maybe there is something missing in my kernel configuration? Let me know if you need more infos or some command output. Thanks in advice
ichise82, Per comment #14, the patch is included in Linux-3.4 -- does linux 3.4 work? Which motherboard do you have, same as Waleed, or other? Does 2.6.38 work?
The original problem posted by the original submitter is fixed and shipped per comment #14 So this bug is closed. ichise82, if you have an additional problem, please open a new bug report.