Re: 2.4.22 hangs upon echo > /proc/acpi/alarm

[Keith Owens <kaos@sgi.com>]

On Wed, 12 Nov 2003 20:33:18 +0800, 
Michael Frank <mhf@linuxmail.org> wrote:
>ACPI version is 20031002
>
>Initial backtrace obtained with kdb:
>
>acpi_os_read_port+36
>acpi_hw_lowlevel_read+7b
>acpi_ev_gpe_detect+94
>acpi_ev_sci_xrupt_handler+3c
>acpi_irq+d
>handle_IRQ_event+31
>do_IRQ+72
>call_do_IRQ+5
>do_softirq+5a
>do_IRQ+a1
>proc_file_write+9b
>sys_write+be
>system_call+33
>
>Further stepping shows endless loop around:
>
>acpi_ev_gpe_detect+80
>  acpi_hw_lowlevel_read
>    acpi_os_read_port
>    acpi_ut_get_region_name
>    acpi_ut_debug_print 
>  acpi_ut_debug_print
>  jmp acpi_ev_gpe_detect+80
>
>Debugging is compiled in, but no meesages go to dmesg
>
>How to enable acpi_ut_debug_print output?

printk() can be called from anywhere but the text is only stored in the
log buffer.  The text is written from the log buffer to the console or
syslog when the kernel is not running in interrupt context.  This is a
common problem with printk, you get no output when debugging interrupt
problems.

Since you have already applied the kdb patch, change acpi to add
#include <linux/kdb.h> and call kdb_printf() instead of printk for
debugging messages.  kdb_printf uses polling mode I/O so you get the
output immediately.