2003-11-12 12:35:48

by Michael Frank

[permalink] [raw]
Subject: 2.4.22 hangs upon echo > /proc/acpi/alarm

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?

Regards
Michael


2003-11-13 01:22:55

by Keith Owens

[permalink] [raw]
Subject: Re: 2.4.22 hangs upon echo > /proc/acpi/alarm

On Wed, 12 Nov 2003 20:33:18 +0800,
Michael Frank <[email protected]> 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.

2003-11-13 18:26:08

by Michael Frank

[permalink] [raw]
Subject: Re: 2.4.22 hangs upon echo > /proc/acpi/alarm

On Thursday 13 November 2003 09:21, Keith Owens wrote:
> On Wed, 12 Nov 2003 20:33:18 +0800,
> Michael Frank <[email protected]> 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.
>

Thank you for your reply. I'll make good use of kdb_printf in future.

In this case however the messages did not even go into the dmesg buffer
as the acpi debug output (via its own printf) must be enabled by debug
section flags which were disabled. I'll file a bug report against acpi asap.

I have two questions about kdb 3.0, x86 hw on 2.4.22 kernel

- is there any netpoll interface for kdb for legacy free hw wo serial port.
- on another non-acpi machine kdb hangs permanently and blinking kbleds stop once
- any key is pressed on the at keyboard
- after about a minute inside kdb (operating via serial port)


Regards
Michael

2003-11-14 00:03:41

by Karol Kozimor

[permalink] [raw]
Subject: Re: 2.4.22 hangs upon echo > /proc/acpi/alarm

Thus wrote Michael Frank:
> Thank you for your reply. I'll make good use of kdb_printf in future.
>
> In this case however the messages did not even go into the dmesg buffer
> as the acpi debug output (via its own printf) must be enabled by debug
> section flags which were disabled. I'll file a bug report against acpi asap.

See http://bugme.osdl.org/show_bug.cgi?id=1320.
Best regards,

--
Karol 'sziwan' Kozimor
[email protected]

2003-11-14 01:21:02

by Keith Owens

[permalink] [raw]
Subject: Re: 2.4.22 hangs upon echo > /proc/acpi/alarm

On Fri, 14 Nov 2003 02:24:43 +0800,
Michael Frank <[email protected]> wrote:
>I have two questions about kdb 3.0, x86 hw on 2.4.22 kernel

kdb 3.0 is ancient, current is kdb v4.3.

> - is there any netpoll interface for kdb for legacy free hw wo serial port.

No netpoll interface. netpoll is not in the standard kernel, kdb
patches are only against the standard kernels.

For legacy free hardware, kdb v4.3 has a working USB keyboard polled
mode. Build with

CONFIG_USB=y
CONFIG_USB_UHCI=y (or OHCI)
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_USB_KBD=y
CONFIG_KDB_USB=y

> - on another non-acpi machine kdb hangs permanently and blinking kbleds stop once
> - any key is pressed on the at keyboard
> - after about a minute inside kdb (operating via serial port)

Sounds like kdb is itself dying. Insufficient data to diagnose, in any
case there have been a lot of bug fixes and enhancements to kdb since
v3.0.