/proc/acpi/alarm halfway working

Hi,
I've just tested 2.6.0-test5-mm4, it seems that the /proc/acpi/alarm has ceased to deadlock my laptop and actually started to work as expected. The only drawback is:
#v+
irq 9: nobody cared!

Call Trace:
 [<c010c57e>] __report_bad_irq+0x2a/0x8b
 [<c010c668>] note_interrupt+0x6f/0x9f
 [<c010c856>] do_IRQ+0xe2/0xe4
 [<c02d1668>] common_interrupt+0x18/0x20
 [<c01f007b>] sys_shmat+0x1f6/0x2b6
 [<c012256c>] do_softirq+0x40/0x97
 [<c010c83d>] do_IRQ+0xc9/0xe4
 [<c02d1668>] common_interrupt+0x18/0x20
 [<c01fb045>] acpi_os_write_port+0x33/0x35
 [<c020f8aa>] acpi_hw_low_level_write+0x118/0x122
 [<c021e6fe>] acpi_ut_trace+0x28/0x2c
 [<c020f5cf>] acpi_hw_register_write+0xca/0x16b
 [<c020f26a>] acpi_set_register+0x1d0/0x2aa
 [<c02232ce>] acpi_system_write_alarm+0x497/0x520
 [<c0150711>] vfs_write+0xbc/0x127
 [<c0150821>] sys_write+0x42/0x63
 [<c02d14fb>] syscall_call+0x7/0xb

handlers:
[<c01faed6>] (acpi_irq+0x0/0x16)
Disabling IRQ #9
#v-

This happens upon the first echo > proc/acpi/alarm. The echo, however, sets the time right, and the system is actually woken up successfully (S1, S3, S4 were tested). Subsequent echos work, but do not generate the above messages. Since IRQ 9 is what ACPI resides on, almost no new events are reported (except those explicitely trigerred by _WAK).
The chipset is i845M; tell me if full dmesg is needed.
Best regards,

Karol 'sziwan' Kozimor
[email protected]

Sorry it's taken so long to reply, but I've finally had a chance to track this down. Could you try the following patch and let me know if it fixes the problem for you?

Thanks,

Pat

===== drivers/acpi/utilities/utglobal.c 1.28 vs edited =====

@@ -358,7 +358,7 @@
 	/* ACPI_EVENT_GLOBAL        */  {ACPI_BITREG_GLOBAL_LOCK_STATUS,    ACPI_BITREG_GLOBAL_LOCK_ENABLE,  ACPI_BITMASK_GLOBAL_LOCK_STATUS,    ACPI_BITMASK_GLOBAL_LOCK_ENABLE},
 	/* ACPI_EVENT_POWER_BUTTON  */  {ACPI_BITREG_POWER_BUTTON_STATUS,   ACPI_BITREG_POWER_BUTTON_ENABLE, ACPI_BITMASK_POWER_BUTTON_STATUS,   ACPI_BITMASK_POWER_BUTTON_ENABLE},
 	/* ACPI_EVENT_SLEEP_BUTTON  */  {ACPI_BITREG_SLEEP_BUTTON_STATUS,   ACPI_BITREG_SLEEP_BUTTON_ENABLE, ACPI_BITMASK_SLEEP_BUTTON_STATUS,   ACPI_BITMASK_SLEEP_BUTTON_ENABLE},
-	/* ACPI_EVENT_RTC           */  {ACPI_BITREG_RT_CLOCK_STATUS,       ACPI_BITREG_RT_CLOCK_ENABLE,     0,                                  0},
+	/* ACPI_EVENT_RTC           */  {ACPI_BITREG_RT_CLOCK_STATUS,       ACPI_BITREG_RT_CLOCK_ENABLE,	ACPI_BITMASK_RT_CLOCK_STATUS,	ACPI_BITMASK_RT_CLOCK_ENABLE},
 };
 
 /*****************************************************************************

===== drivers/acpi/sleep/proc.c 1.7 vs edited =====

@@ -1,3 +1,4 @@
+#include <linux/interrupt.h>
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
 #include <linux/suspend.h>

@@ -370,6 +371,14 @@
 };
 
 
+static u32 rtc_handler(void * context)
+{
+	acpi_set_register(ACPI_BITREG_RT_CLOCK_STATUS, 1, ACPI_MTX_LOCK);
+	acpi_set_register(ACPI_BITREG_RT_CLOCK_ENABLE, 0, ACPI_MTX_LOCK);
+	return IRQ_HANDLED;
+}
+
+
 static int acpi_sleep_proc_init(void)
 {
 	struct proc_dir_entry	*entry = NULL;

@@ -385,6 +394,8 @@
 		S_IFREG|S_IRUGO|S_IWUSR, acpi_root_dir);
 	if (entry)
 		entry->proc_fops = &acpi_system_alarm_fops;
+
+	acpi_install_fixed_event_handler(ACPI_EVENT_RTC, rtc_handler, NULL);
 	return 0;
 }