Most recent kernel where this bug did *NOT* occur: Distribution: Hardware Environment: Intel Mobile, i386, single processor. Normal ICH with HPET Software Environment: BOOT, HPET built in the kernel Problem Description: In file linux/arch/i386/kernel/time_hpet.c, function hpet_enable. The HPET uses the IRQ2(HPET_LEGACY_8254) and IRQ8(HPET_LEGACY_RTC) as default for setting up HPET legacy mode. But in Intel HPET spec, the IRQ2 is used only when IOAPIC is enabled, otherwise it is routed to PIC IRQ0. So there is a conflication for it. It should judge the mode first. And later in linux/arch/i386/kernel/time.c, function hpet_time_init(). It will call time_init_hook, which uses the IRQ0. void __init time_init_hook(void) { setup_irq(0, &irq0); } Steps to reproduce:
(added a few people)
Is this an issue you have with some system where kernel is not able to use HPET. Or is this something you found by code inspection and reading HPET doc? HPET timer interrupts appear as IRQ0 to kernel either with IOAPIC or 8259. The IRQ 2 (HPET_LEGACY_8254) is only for hpet driver (drivers/char/hpet.c) and kernel reserves both timer 0 and timer 1 (When RTC emulation is enabled) and driver will not use these.
When I use the Kernel 2.6.20 for power on the new UMPC platform, it will cause the HLT instruction (In /asm-i386/bugs.h, check_bugs(), which calls check_hlt())making the processor halt. The reason is that no interrupt occurs at that point. The additional kernel command is "console=ttyS0,115200n8 console=tty0" for Fedora 4. HPET appears as either IRQ0 for 8259 or acts as IRQ2 for IOAPIC. It depends on which interrupt controller runs. As I am not a Linux kernel expert, it may have mistake for my understanding the kernel code. When I disabling the HPET support in kernel , it works well for HLT at check_hlt().
Di, Can you please collect a boot trace with "debug apic=debug" boot parameters when you get such failure? Thanks.
Contacted Di and the bug can not be reproduced any more.