Bug 42700
Summary: | Kernel won't boot on D102GGC2 board unless ACPI=off or idle=halt | ||
---|---|---|---|
Product: | ACPI | Reporter: | Waleed Hamra (kernel-bugs) |
Component: | ACPICA-Core | Assignee: | Len Brown (lenb) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | florian, ichise82, kernel-bugs, lenb, rui.zhang |
Priority: | P1 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 3.* | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
dmesg output on 2.6
lspci -vvnn dmidecode sudo acpidump 001-ACPICA-Fix-regression-in-FADT-revision-checks.patch |
Description
Waleed Hamra
2012-01-31 05:55:57 UTC
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. |