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

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

[Karol Kozimor]

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
sziwan@hell.org.pl

2.4.22 hangs upon echo > /proc/acpi/alarm

[Michael Frank]

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

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

[Keith Owens]

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.

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

[Michael Frank]

On Thursday 13 November 2003 09:21, Keith Owens wrote:
> 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.
> 

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

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

[Keith Owens]

On Fri, 14 Nov 2003 02:24:43 +0800, 
Michael Frank <mhf@linuxmail.org> 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.