This has been most evidenced by Ubuntu Intrepid (see here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/272247?comments=all ) But I have had the same issue using openSUSE 11.1 x86_64 and that bug I linked to has a bunch of duplicates also. That bug on launchpad has more information than I could hope to condense here, but it's quite a few people who are having this issue.
Will you please try the following boot options and see whether the issue still exists? a. nolapic_timer b. processor.max_cstate=1 c. idle=poll Please also attach the output of acpidump. Thanks.
Created attachment 20949 [details] acpidump from my computer ran acpidump as requested.
nolapic_timer Boots fine, powers down fine. On power down, seems to take longer, and it keeps on coming up as if I was logging into a tty rather than shutting down, two/three times it does this, but continues powering down. (probably just random, inconsequential.) idle=poll boots and powers down fine, switched to make this current option in Grub rather than having the boot freeze on me. processor.max_cstate=1 Boot freezes like original report, but can continue (like original report.) Powers down fine. I don't know if you read my last comments on the linked bug on launchpad, my boot completely broke, I dropped to busybox, with one option, "nolapic", but as stated above, "nolapic_timer" makes it boot fine. That might have just been me though, I don't know.
thanks for the test. It seems that the box can be booted when the C-state is disabled or the boot option of "nolapic_timer" is added. In fact when the boot option of "nolapic" is added, the local APIC will be disabled. Of course the local APIC timer won't be used. It means that the local APIC timer is also disabled when the boot option of "nolapic" is added. But from the log on launchpad it seems that the box can be booted if the boot option of "acpi=noirq" is added. I don't know why this issue can be workaround by the boot option of "acpi=noirq". Hi, Venki Any idea about the boot option of "acpi=noirq"? Thanks.
please try 2.6.29 from kernel.org
Turns out it's due to a badly coded DSDT, not much the kernel team can do about that. Mine is fixed, and I plan on asking HP to use the Intel Compiler in the future, rather than the MSFT one they used, as the MSFT one ignores many errors and continues on regardless, causing issues like this.
If the system works with Windows, then it should work with Linux also -- out of the box. Modifying the DSDT to make Linux work is useful for debugging, but absolutely not viable for a supported system. re-opening.
The boot stall is surely because of missing timer interrupts. Perhaps the quirk to disable the bogus interrupt override on nvidia chipsets is not working... Please try booting with "acpi_skip_timer_override" and in case we got it backwards, then try with "acpi_use_timer_override" Please attach the output of lspci -vv and dmesg -s64000 and identify the system vendor and model number.
how about boot option 'highres=off nohz=off'? if it works, please try boot option 'nohz=off'. I suspect lapic timer doesn't work in one shot mode when cpu can enter c-state in AMD cpu.
please try the patch in http://bugzilla.kernel.org/show_bug.cgi?id=13233, comment #19. Somebody says the patch works for him.
ping Michael Douglas.
Pong. Apologies for not doing any further work, I've been more than a little busy just now, IRL, so this has not been a focus, since the modified DSDT fixed it for me. I will get another (unpatched) kernel, which is doing the issue, and try the suggested options.
close this bug as there is no response for a month. please re-open it if the problem still exists in the latest git kernel and you can provide the info requested in comment #10.