Hm ..., can you mail /proc/interrupts of the affected system? According
to the HPET specification
General Interrupt Status Register Field Definitions
--------------------------------------------------------
T2_INT_STS Timer 2 Interrupt Active: Same functionality as Timer 0.
T1_INT_STS Timer 1 Interrupt Active: Same functionality as Timer 0.
T0_INT_STS Timer 0 Interrupt Active:
The functionality of this bit depends on whether the edge
or level-triggered mode is used for this timer:
If set to level-triggered mode:
This bit defaults to 0. This bit will be set by
hardware if the corresponding timer interrupt is
active. Once the bit is set, it can be cleared by
software writing a 1 to the same bit position.
Writes of 0 to this bit will have no effect. For
example, if the bit is already set a write of 0
will not clear the bit.
If set to edge-triggered mode:
This bit should be ignored by software. Software
should always write 0 to this bit.
--------------------------------------------------------
On all systems I checked the interrupt is edge-triggered. So, if your
interrupt is level triggered, that might be the cause.
Well, can you disable CONFIG_HPET_EMULATE_RTC entirely and try again?
Can you try that patch and see if the IRQ handler is really called
repeatedly in that case?
Bernhard
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -679,6 +679,9 @@ irqreturn_t hpet_rtc_interrupt(int irq,
{
struct rtc_time curr_time;
unsigned long rtc_int_flag = 0;
+ struct hpet __iomem *hpet = hpet_virt_address;
+
+ printk(KERN_INFO "status=%d\n", readl(&hpet->hpet_isr));
hpet_rtc_timer_reinit();
memset(&curr_time, 0, sizeof(struct rtc_time));
--- a/include/asm-x86/hpet.h
+++ b/include/asm-x86/hpet.h
@@ -35,6 +35,10 @@
#define HPET_LEGACY_8254 2
#define HPET_LEGACY_RTC 8
+#define HPET_T0_INT_STS (1<<0)
+#define HPET_T1_INT_STS (1<<1)
+#define HPET_T2_INT_STS (1<<2)
+
#define HPET_TN_LEVEL 0x0002
#define HPET_TN_ENABLE 0x0004
#define HPET_TN_PERIODIC 0x0008
--
