I try the kernels: 2.6.24(Debian), 2.6.25(Debian) and 2.6.26(vanilla) and all they failed to boot. Distribution: Debian Lenny Hardware Environment: Intel Core 2 Duo T8300, ChipSet: Mobile Intel PM 965 Express, ATI Radeon HD2400 Problem Description: System stops soon in the boot process with acpi enabled. I try to insolate the problem trying different boot options (acpi=off, acpi=ht, pci=noacpi, acpi=noirq, pnpacpi=off, noapic, nolapic) with no luck (only with acpi=off, acpi=ht the system boots). In normal mode (no quiet) the last lines befote hang are: … ACPI: ACPI0007:01 is registered as cooling_device1 Marking TSC unstable due to: TSC halts inside The system comes with Windows Vista, and I don’t know if this is important, but for downgrading to Windows XP, you have to change the BIOS
Created attachment 16918 [details] acpidump output
Created attachment 16919 [details] lspci -vv output
Created attachment 16920 [details] dmidecode output
Created attachment 16921 [details] /proc/interrupts
Hi, Jaime Will you confirm whether the Windows(vista & XP) can be booted with ACPI enabled? After the system is booted, please open the device manager and check whether the IRQ 9 type is the microsoft ACPI-compliant system(Noted: please select the menuitem of resources by type in the view menu). Will you please try the boot option of "hpet=off" and see whether the system can be booted? Thanks.
Sorry, the boot option of "hpet=off" is incorrect. Please the correct boot option should be "hpet=disable" Thanks.
how about boot option acpi_processor.max_cstate=1
Will you please try the boot option of "processor.max_cstate=1" and see whether the system can be booted with acpi enabled? Thanks.
Thank you for the answers. Yesterday night I could try your suggestions. The system doesn’t boot with the options “hpet=disable” or “processor.max_cstate=1”. It hangs, with a naked eye, at the same point. And the other question. Windows Vista boots with ACPI enabled. I’ve checked IRQs and: - IRQ 9 is not assigned to anything. - Microsoft ACPI-compliant has assigned IRQs from 80 (0x00000050) to 190 (0x000000BE). Thanks again.
Hi, Jaime Thanks for the test. Will you please enable the "CONFIG_ACPI_DEBUG" in kernel configuration and boot the system with the option of "acpi.debug_layer=0x04010000 acpi.debug_level=0x17"? When the system still freezes, please capture the picture and attach it. Thanks.
Hi, I make the boot test with enabled debug. The last two lines, before the system freezes, are: ....... [1.877254] Marking TSC unstable due to: TSC halts in idle [1.880941] utils-0047 [00] util_eval_error : Evaluate [\_TZ_._TMP]: AE_NOT_FOUND If you need the picture I can attach it. Thanks
Created attachment 17021 [details] debug boot test boot test with kernel option "CONFIG_ACPI_DEBUG" enabled and booted with options "acpi.debug_layer=0x04010000" "acpi.debug_level=0x17"
Will you please add the boot option of "notsc" and see whether the problem still exists? But the following is very weird. > The utils-0047 [00] util_eval_error : Evaluate [\_TZ_._TMP]: AE_NOT_FOUND From the acpidump we can know that the correct path should be \_TZ.THRM._TMP Thanks.
How about disabling acpi thermal driver? If it hangs, please let us know the last several lines?
Hi, I've tested the options "notsc" and "thermal.off=1" with acpi debug enabled, and the system hangs at the hangs at the same point. NOTE: I don't if I've used the correct way of disabling the thermal driver.
(In reply to comment #15) > Hi, > I've tested the options "notsc" and "thermal.off=1" with acpi debug enabled, > and the system hangs at the hangs at the same point. > > NOTE: I don't if I've used the correct way of disabling the thermal driver. > Maybe using debug.acpi.disable="thermal"
(In reply to comment #16) > (In reply to comment #15) > > Hi, > > I've tested the options "notsc" and "thermal.off=1" with acpi debug > enabled, > > and the system hangs at the hangs at the same point. > > > > NOTE: I don't if I've used the correct way of disabling the thermal driver. > > > > Maybe using debug.acpi.disable="thermal" > No, "thermal.off=1" is right. Please attach the screenshot with thermal.off=1
Created attachment 17509 [details] thermal off boot test screenshot boot test disabling thermal driver. Boot options: "acpi.debug_layer=0x04010000" "acpi.debug_level=0x17" "thermal.off=1"
Hi, Jaime Thanks for the info. From the info in comment #9 it seems that maybe the ACPI is disabled on windows vista. >- IRQ 9 is not assigned to anything. >- Microsoft ACPI-compliant has assigned IRQs from 80 (0x00000050) to 190 (0x000000BE). In fact the IRQ 9 is defined for the ACPI-compliant system in ACPI tables. There exists the following definitions in the FADT table. >SCI Interrupt : 0009 There exists the following definitions in the APIC table. > [062h 098 1] Sub-Table Type : 02 <Interrupt Source > Override> >[063h 099 1] Length : 0A >[064h 100 1] Bus : 00 >[065h 101 1] Source : 09 >[066h 102 4] Interrupt : 00000009 >[06Ah 106 2] Flags (decoded below) : 000F Will you please try the boot option of "idle=poll" and see whether the system can be booted with ACPI enabled? Will you please compile the driver/acp/processor as built-in module and add the boot option of "processor.max_cstate=1" to see whether the system can be booted with ACPI enabled? thanks. Thanks.
Hi, The system boots with the option "idle=poll". :) And, I didn't try enough, but acpi seems to work ok. I attach the dmesg output. This afternoon I'm going to try the compilation of the driver/acp/processor as built-in. Thanks a lot.
Created attachment 17570 [details] dmesg output (using "idle=poll") dmesg output. With acpi enabled and using the option "idle=poll". Boot options: "acpi.debug_layer=0x04010000" "acpi.debug_level=0x17" "idle=poll"
Hi, Finally, I've tried the compilation of the driver/acp/processor as built-in with the option "processor.max_cstate=1" and the system doesn't boot. Thanks.
Hi, Jaime It is weird that the boot option of "processor.max_cstate=1" still can't make the system work while the boot option of "idle=poll" can work. Will you please try the following boot option on the latest kernel(2.6.27-rc5) and see whether the system can be booted ? a. idle=nomwait b. nolapic_timer c. idle=halt Will you please attach the following outputs? ./acpidump --addr 0xBFFCE190 --length 0x267 -o cpu0ist ./acpidump --addr 0xBFFCE490 --length 0x594 -o cpu0cst Thanks.
Created attachment 17750 [details] acpidump cpu0ist acpidump --addr 0xBFFCE190 --length 0x267 -o cpu0ist
Created attachment 17751 [details] acpidump cpu0cst acpidump --addr 0xBFFCE490 --length 0x594 -o cpu0cst
Hi, On the latest kernel(2.6.27-rc6): "nolapic_timer" -> the system boots "idle=nomwait" or "idle=halt" -> the system doesn't boot Thanks
Hi again, Which workaround is better "idle=poll" or "nolapic_timer"?
Of course the "nolapic_timer" is better. In such case the C-state is still used. Thanks.
Hi, Jaime Will you please try the latest kernel(2.6.28-rc4) and see whether the system can be booted with ACPI enabled? Thanks.
Hi Zhao, Sorry for the delay. I'he try the kernel 2.6.28-rc5, but the system does not boot with ACPI enabled. I haven't take a screenshot, but if you need I can take it. Thanks.
Hi, Jaime Thanks for the confirmation that the issue still exists on the 2.6.28-rc5 kernel. From the test result it seems that this issue is related with the C-states. If the C-state is disabled or "nolapic_timer" is added, the system can be booted very normally. So the problem summary will be changed as: the system can't be booted unless C-state is disabled or the boot option of "nolapic_timer" is added. thanks.
Hi, Venki Do you have opportunity to look at this issue? Thanks.
Jaime, Can you attach the dmesg output when you boot with "nolapic_timer" Thanks.
Created attachment 19223 [details] dmesg output (using "idle=poll") dmesg output. With acpi enabled and using the option "nolapic_timer". Kernel: 2.6.28-rc7 Boot options: "acpi.debug_layer=0x04010000" "acpi.debug_level=0x17" "nolapic_timer"
Hello Venkatesh, Without "nolapic_timer" boot option, the system hangs at this point: [ 1.936910] ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3]) [ 1.937104] processor ACPI0007:01: registered as cooling_device1 [ 1.937146] scan-0369 [00] device_probe : Found driver [processor] for device [P002] [ 1.938459] utils-0047 [00] util_eval_error : Evaluate [\_TZ_._TMP]: AE_NOT_FOUND Thanks
How about boot option maxcpus=1?
The system boots OK with the option "maxcpus=1". I've attached the dmesg output.
Created attachment 19455 [details] dmesg output (using "maxcpus=1") dmesg output. With acpi enabled and using the option "maxcpus=1". Kernel: 2.6.28-rc7 Boot options: "acpi.debug_layer=0x04010000" "acpi.debug_level=0x17" "maxcpus=1"
Ubuntu works great if deactivating in BIOS the two cores of the processor, with the option Core Multi-Processing disabled. With this method all works but the ethernet doesn't and you only will have one core used.
Hi, Jaime Will you please unset the CONFIG_ACPI_IDLE in kernel configuration and see whether the box can be booted normally? (this had better be done on the 2.6.28.x stable kernel). Thanks.
Hi, I didn't find CONFIG_ACPI_IDLE option. The most similar one I found was CONFIG_CPU_IDLE. Did you refer to this option? Well, I unset CONFIG_CPU_IDLE in stable kernel 2.6.28.7 and I tried it. The system doesn't boot with this configuration. It hangs very very early just after "Loading..." message. Thanks
Hi, Jaime Thanks for the test. Sorry for my typo. It should be CONFIG_CPU_IDLE instead of CONFIG_ACPI_IDLE. From the test it seems that the box can be booted when lapic_timer is not used or C-state is disabled. Even when the boot option of "processor.max_cstate=1"/"idle=halt" is added, it still can't be booted normally. When adding "idle=halt", halt is used when the system is in idle state. It seems that in such case the cpu can't be waked by local apic timer. Hi, Venki Any idea about this issue? Thanks.
ping Venki... :)
Can you try latest kernel, there are a lot of idle related fixes in?
Hi, I've tried 2.6.30 and 2.6.31-rc2 and unfortunately the system continues without booting. At first glance, it hangs more or less at the same point. Thanks
Hi, Jaime Please add the boot option of "nolapic_timer" on your box. It seems that the box can't be waked up by local APIC timer even when only C1 is used. Maybe it is related with the BIOS. thanks.
Thanks Zhao, In fact, I actually use the "nolapic_timer" option and with it, the box works quite well as you said. I don't know in depth the consequence of the using this option versus not using it, but the fact is that it works. Thanks again.
I was having the same problem. In the latest Kubuntu 9.10 version, this problem has been fixed, it runs without "nolapic_timer" option. All the best. 2009/11/9 <bugzilla-daemon@bugzilla.kernel.org> > http://bugzilla.kernel.org/show_bug.cgi?id=11135 > > > > > > --- Comment #48 from Jaime Gimeno <xaumexemuax@yahoo.es> 2009-11-09 > 09:55:01 --- > Thanks Zhao, > In fact, I actually use the "nolapic_timer" option and with it, the box > works > quite well as you said. I don't know in depth the consequence of the using > this > option versus not using it, but the fact is that it works. > Thanks again. > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. >
Hello Zhao, Good news! As Abel Pascual commented, this bug has been fixed in recent kernels. Yesterday, I've tried latest stable kernel 2.6.31.6 and it boots without any problem and without using "nolapic_timer" option. Until now, I was using kernel 2.6.30, in which the problem existed. Thank you very much for all.
I have no idea why it can be fixed by a kernel update. it would be great if we can find out which commit fixes this bug... close it for now.
Well, I'm ready to check what you want. But, what kernel versions should I try?
Can you use the git-bisect to identify this good commit? Thanks.