* 2.6.3 Oops when power-off via sys-rq
@ 2004-02-26 12:52 Alexander Y. Fomichev
0 siblings, 0 replies; 4+ messages in thread
From: Alexander Y. Fomichev @ 2004-02-26 12:52 UTC (permalink / raw)
To: linux-kernel; +Cc: Sergey S. Kostyliov
Hello!
I get an oops any time when try to poweroff my 2xAthlon MP 2400 box [2.6.3]
via SysRq: poweroff. Instead of poweroff i see an oops and box
appears to be locked. This is not a significant problem for me,
but also not looks like a normal behaviour.
Here is a trace:
SysRq : Power Off
acpi_power_off called
bad: scheduling while atomic!
Call Trace:
[<c011b79e>] schedule+0x68e/0x6a0
[<c01fd4c1>] acpi_ut_release_mutex+0x67/0x6c
[<c01fc605>] acpi_ut_acquire_from_cache+0x44/0x9e
[<c0128520>] __mod_timer+0x180/0x220
[<c01291fb>] schedule_timeout+0x6b/0xc0
[<c0129180>] process_timeout+0x0/0x10
[<c01f1cf2>] acpi_ex_system_do_suspend+0x1f/0x28
[<c01f0d1c>] acpi_ex_opcode_1A_0T_0R+0x48/0x8d
[<c01ead21>] acpi_ds_exec_end_op+0xad/0x268
[<c01f7fd6>] acpi_ps_parse_loop+0x516/0x821
[<c01fd5f3>] acpi_ut_delete_generic_state+0xb/0xe
[<c01fe34b>] acpi_ut_update_object_reference+0x1ec/0x22a
[<c01fe3a1>] acpi_ut_add_reference+0x18/0x1c
[<c01ea10c>] acpi_ds_method_data_set_value+0x29/0x36
[<c01fd444>] acpi_ut_acquire_mutex+0x5c/0x72
[<c01fd4c1>] acpi_ut_release_mutex+0x67/0x6c
[<c01fc605>] acpi_ut_acquire_from_cache+0x44/0x9e
[<c01f832f>] acpi_ps_parse_aml+0x4e/0x17b
[<c01f8bc6>] acpi_psx_execute+0x142/0x19c
[<c01f5f69>] acpi_ns_execute_control_method+0x43/0x52
[<c01f5f02>] acpi_ns_evaluate_by_handle+0x6f/0x93
[<c01f5e79>] acpi_ns_evaluate_by_name+0x6d/0x87
[<c01f56c8>] acpi_evaluate_object+0xcf/0x1be
[<c01f47ba>] acpi_enter_sleep_state_prep+0x5a/0xce
[<c01fecf6>] acpi_power_off+0x16/0x22
[<c013a28d>] handle_poweroff+0xd/0x10
[<c0219853>] __handle_sysrq_nolock+0x73/0xe0
[<c02197ca>] handle_sysrq+0x4a/0x60
[<c0213663>] kbd_event+0x33/0x60
[<c02607ef>] input_event+0xef/0x400
[<c02627fe>] atkbd_report_key+0x3e/0xa0
[<c0262a0d>] atkbd_interrupt+0x1ad/0x3e0
[<c02669ff>] serio_interrupt+0x5f/0x70
[<c02672af>] i8042_interrupt+0xaf/0x170
[<c010b49a>] handle_IRQ_event+0x3a/0x70
[<c010b875>] do_IRQ+0xb5/0x190
[<c0105000>] _stext+0x0/0x70
[<c0109b08>] common_interrupt+0x18/0x20
[<c0106c30>] default_idle+0x0/0x40
[<c0105000>] _stext+0x0/0x70
[<c0106c5c>] default_idle+0x2c/0x40
[<c0106ce3>] cpu_idle+0x33/0x40
[<c034c8c2>] start_kernel+0x172/0x190
[<c034c470>] unknown_bootoption+0x0/0x100
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c011b244
*pde = 00000000
Oops: 0002 [#1]
CPU: 0
EIP: 0060:[<c011b244>] Not tainted
EFLAGS: 00010097
EIP is at schedule+0x134/0x6a0
eax: 00000001 ebx: 00000000 ecx: c0305420 edx: c0305420
esi: c0305420 edi: c2419c00 ebp: c034bc44 esp: c034bbf0
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c034a000 task=c0305420)
Stack: c02d75e0 c01fd4c1 f7ffef40 00000001 c24f8500 0000003c c01fc605 00000009
00000000 0000000b 00000001 c034a000 c2419c00 0f761f8c 393a0609 0000000d
c0305420 c03055e8 fffc53f0 c034bc58 00000000 c2462a40 c01291fb c034bc58
Call Trace:
[<c01fd4c1>] acpi_ut_release_mutex+0x67/0x6c
[<c01fc605>] acpi_ut_acquire_from_cache+0x44/0x9e
[<c01291fb>] schedule_timeout+0x6b/0xc0
[<c0129180>] process_timeout+0x0/0x10
[<c01f1cf2>] acpi_ex_system_do_suspend+0x1f/0x28
[<c01f0d1c>] acpi_ex_opcode_1A_0T_0R+0x48/0x8d
[<c01ead21>] acpi_ds_exec_end_op+0xad/0x268
[<c01f7fd6>] acpi_ps_parse_loop+0x516/0x821
[<c01fd5f3>] acpi_ut_delete_generic_state+0xb/0xe
[<c01fe34b>] acpi_ut_update_object_reference+0x1ec/0x22a
[<c01fe3a1>] acpi_ut_add_reference+0x18/0x1c
[<c01ea10c>] acpi_ds_method_data_set_value+0x29/0x36
[<c01fd444>] acpi_ut_acquire_mutex+0x5c/0x72
[<c01fd4c1>] acpi_ut_release_mutex+0x67/0x6c
[<c01fc605>] acpi_ut_acquire_from_cache+0x44/0x9e
[<c01f832f>] acpi_ps_parse_aml+0x4e/0x17b
[<c01f8bc6>] acpi_psx_execute+0x142/0x19c
[<c01f5f69>] acpi_ns_execute_control_method+0x43/0x52
[<c01f5f02>] acpi_ns_evaluate_by_handle+0x6f/0x93
[<c01f5e79>] acpi_ns_evaluate_by_name+0x6d/0x87
[<c01f56c8>] acpi_evaluate_object+0xcf/0x1be
[<c01f47ba>] acpi_enter_sleep_state_prep+0x5a/0xce
[<c01fecf6>] acpi_power_off+0x16/0x22
[<c013a28d>] handle_poweroff+0xd/0x10
[<c0219853>] __handle_sysrq_nolock+0x73/0xe0
[<c02197ca>] handle_sysrq+0x4a/0x60
[<c0213663>] kbd_event+0x33/0x60
[<c02607ef>] input_event+0xef/0x400
[<c02627fe>] atkbd_report_key+0x3e/0xa0
[<c0262a0d>] atkbd_interrupt+0x1ad/0x3e0
[<c02669ff>] serio_interrupt+0x5f/0x70
[<c02672af>] i8042_interrupt+0xaf/0x170
[<c010b49a>] handle_IRQ_event+0x3a/0x70
[<c010b875>] do_IRQ+0xb5/0x190
[<c0105000>] _stext+0x0/0x70
[<c0109b08>] common_interrupt+0x18/0x20
[<c0106c30>] default_idle+0x0/0x40
[<c0105000>] _stext+0x0/0x70
[<c0106c5c>] default_idle+0x2c/0x40
[<c0106ce3>] cpu_idle+0x33/0x40
[<c034c8c2>] start_kernel+0x172/0x190
[<c034c470>] unknown_bootoption+0x0/0x100
Code: ff 0b 8b 4d ec 8b 75 ec 83 c1 20 8b 46 20 8b 51 04 89 50 04
and some [possilby useful] info:
http://www.sysadminday.org.ru/2.6.3-sysrq_O-oops/config.txt
http://www.sysadminday.org.ru/2.6.3-sysrq_O-oops/lspci.txt
http://www.sysadminday.org.ru/2.6.3-sysrq_O-oops/lspci-vvn.txt
http://www.sysadminday.org.ru/2.6.3-sysrq_O-oops/cpuinfo.txt
--
Best regards.
Alexander Y. Fomichev <gluk@php4.ru>
Public PGP key: http://sysadminday.org.ru/gluk.asc
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.3 Oops when power-off via sys-rq
[not found] <A6974D8E5F98D511BB910002A50A6647615F3396@hdsmsx402.hd.intel.com>
@ 2004-02-26 22:53 ` Len Brown
2004-02-27 1:14 ` Andrew Morton
0 siblings, 1 reply; 4+ messages in thread
From: Len Brown @ 2004-02-26 22:53 UTC (permalink / raw)
To: Alexander Y. Fomichev; +Cc: linux-kernel, Sergey S. Kostyliov
Alexander,
Please file an bug at bugzilla.kernel.org
category: power management
component: ACPI
thanks,
-Len
On Thu, 2004-02-26 at 07:52, Alexander Y. Fomichev wrote:
> Hello!
>
> I get an oops any time when try to poweroff my 2xAthlon MP 2400 box
> [2.6.3]
> via SysRq: poweroff. Instead of poweroff i see an oops and box
> appears to be locked. This is not a significant problem for me,
> but also not looks like a normal behaviour.
>
> Here is a trace:
>
> SysRq : Power Off
>
> acpi_power_off called
> bad: scheduling while atomic!
> Call Trace:
> [<c011b79e>] schedule+0x68e/0x6a0
> [<c01fd4c1>] acpi_ut_release_mutex+0x67/0x6c
> [<c01fc605>] acpi_ut_acquire_from_cache+0x44/0x9e
> [<c0128520>] __mod_timer+0x180/0x220
> [<c01291fb>] schedule_timeout+0x6b/0xc0
> [<c0129180>] process_timeout+0x0/0x10
> [<c01f1cf2>] acpi_ex_system_do_suspend+0x1f/0x28
> [<c01f0d1c>] acpi_ex_opcode_1A_0T_0R+0x48/0x8d
> [<c01ead21>] acpi_ds_exec_end_op+0xad/0x268
> [<c01f7fd6>] acpi_ps_parse_loop+0x516/0x821
> [<c01fd5f3>] acpi_ut_delete_generic_state+0xb/0xe
> [<c01fe34b>] acpi_ut_update_object_reference+0x1ec/0x22a
> [<c01fe3a1>] acpi_ut_add_reference+0x18/0x1c
> [<c01ea10c>] acpi_ds_method_data_set_value+0x29/0x36
> [<c01fd444>] acpi_ut_acquire_mutex+0x5c/0x72
> [<c01fd4c1>] acpi_ut_release_mutex+0x67/0x6c
> [<c01fc605>] acpi_ut_acquire_from_cache+0x44/0x9e
> [<c01f832f>] acpi_ps_parse_aml+0x4e/0x17b
> [<c01f8bc6>] acpi_psx_execute+0x142/0x19c
> [<c01f5f69>] acpi_ns_execute_control_method+0x43/0x52
> [<c01f5f02>] acpi_ns_evaluate_by_handle+0x6f/0x93
> [<c01f5e79>] acpi_ns_evaluate_by_name+0x6d/0x87
> [<c01f56c8>] acpi_evaluate_object+0xcf/0x1be
> [<c01f47ba>] acpi_enter_sleep_state_prep+0x5a/0xce
> [<c01fecf6>] acpi_power_off+0x16/0x22
> [<c013a28d>] handle_poweroff+0xd/0x10
> [<c0219853>] __handle_sysrq_nolock+0x73/0xe0
> [<c02197ca>] handle_sysrq+0x4a/0x60
> [<c0213663>] kbd_event+0x33/0x60
> [<c02607ef>] input_event+0xef/0x400
> [<c02627fe>] atkbd_report_key+0x3e/0xa0
> [<c0262a0d>] atkbd_interrupt+0x1ad/0x3e0
> [<c02669ff>] serio_interrupt+0x5f/0x70
> [<c02672af>] i8042_interrupt+0xaf/0x170
> [<c010b49a>] handle_IRQ_event+0x3a/0x70
> [<c010b875>] do_IRQ+0xb5/0x190
> [<c0105000>] _stext+0x0/0x70
> [<c0109b08>] common_interrupt+0x18/0x20
> [<c0106c30>] default_idle+0x0/0x40
> [<c0105000>] _stext+0x0/0x70
> [<c0106c5c>] default_idle+0x2c/0x40
> [<c0106ce3>] cpu_idle+0x33/0x40
> [<c034c8c2>] start_kernel+0x172/0x190
> [<c034c470>] unknown_bootoption+0x0/0x100
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> printing eip:
> c011b244
> *pde = 00000000
> Oops: 0002 [#1]
> CPU: 0
> EIP: 0060:[<c011b244>] Not tainted
> EFLAGS: 00010097
> EIP is at schedule+0x134/0x6a0
> eax: 00000001 ebx: 00000000 ecx: c0305420 edx: c0305420
> esi: c0305420 edi: c2419c00 ebp: c034bc44 esp: c034bbf0
> ds: 007b es: 007b ss: 0068
> Process swapper (pid: 0, threadinfo=c034a000 task=c0305420)
> Stack: c02d75e0 c01fd4c1 f7ffef40 00000001 c24f8500 0000003c c01fc605
> 00000009
> 00000000 0000000b 00000001 c034a000 c2419c00 0f761f8c 393a0609
> 0000000d
> c0305420 c03055e8 fffc53f0 c034bc58 00000000 c2462a40 c01291fb
> c034bc58
> Call Trace:
> [<c01fd4c1>] acpi_ut_release_mutex+0x67/0x6c
> [<c01fc605>] acpi_ut_acquire_from_cache+0x44/0x9e
> [<c01291fb>] schedule_timeout+0x6b/0xc0
> [<c0129180>] process_timeout+0x0/0x10
> [<c01f1cf2>] acpi_ex_system_do_suspend+0x1f/0x28
> [<c01f0d1c>] acpi_ex_opcode_1A_0T_0R+0x48/0x8d
> [<c01ead21>] acpi_ds_exec_end_op+0xad/0x268
> [<c01f7fd6>] acpi_ps_parse_loop+0x516/0x821
> [<c01fd5f3>] acpi_ut_delete_generic_state+0xb/0xe
> [<c01fe34b>] acpi_ut_update_object_reference+0x1ec/0x22a
> [<c01fe3a1>] acpi_ut_add_reference+0x18/0x1c
> [<c01ea10c>] acpi_ds_method_data_set_value+0x29/0x36
> [<c01fd444>] acpi_ut_acquire_mutex+0x5c/0x72
> [<c01fd4c1>] acpi_ut_release_mutex+0x67/0x6c
> [<c01fc605>] acpi_ut_acquire_from_cache+0x44/0x9e
> [<c01f832f>] acpi_ps_parse_aml+0x4e/0x17b
> [<c01f8bc6>] acpi_psx_execute+0x142/0x19c
> [<c01f5f69>] acpi_ns_execute_control_method+0x43/0x52
> [<c01f5f02>] acpi_ns_evaluate_by_handle+0x6f/0x93
> [<c01f5e79>] acpi_ns_evaluate_by_name+0x6d/0x87
> [<c01f56c8>] acpi_evaluate_object+0xcf/0x1be
> [<c01f47ba>] acpi_enter_sleep_state_prep+0x5a/0xce
> [<c01fecf6>] acpi_power_off+0x16/0x22
> [<c013a28d>] handle_poweroff+0xd/0x10
> [<c0219853>] __handle_sysrq_nolock+0x73/0xe0
> [<c02197ca>] handle_sysrq+0x4a/0x60
> [<c0213663>] kbd_event+0x33/0x60
> [<c02607ef>] input_event+0xef/0x400
> [<c02627fe>] atkbd_report_key+0x3e/0xa0
> [<c0262a0d>] atkbd_interrupt+0x1ad/0x3e0
> [<c02669ff>] serio_interrupt+0x5f/0x70
> [<c02672af>] i8042_interrupt+0xaf/0x170
> [<c010b49a>] handle_IRQ_event+0x3a/0x70
> [<c010b875>] do_IRQ+0xb5/0x190
> [<c0105000>] _stext+0x0/0x70
> [<c0109b08>] common_interrupt+0x18/0x20
> [<c0106c30>] default_idle+0x0/0x40
> [<c0105000>] _stext+0x0/0x70
> [<c0106c5c>] default_idle+0x2c/0x40
> [<c0106ce3>] cpu_idle+0x33/0x40
> [<c034c8c2>] start_kernel+0x172/0x190
> [<c034c470>] unknown_bootoption+0x0/0x100
>
> Code: ff 0b 8b 4d ec 8b 75 ec 83 c1 20 8b 46 20 8b 51 04 89 50 04
>
> and some [possilby useful] info:
>
> http://www.sysadminday.org.ru/2.6.3-sysrq_O-oops/config.txt
> http://www.sysadminday.org.ru/2.6.3-sysrq_O-oops/lspci.txt
> http://www.sysadminday.org.ru/2.6.3-sysrq_O-oops/lspci-vvn.txt
> http://www.sysadminday.org.ru/2.6.3-sysrq_O-oops/cpuinfo.txt
>
>
> --
> Best regards.
> Alexander Y. Fomichev <gluk@php4.ru>
> Public PGP key: http://sysadminday.org.ru/gluk.asc
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.3 Oops when power-off via sys-rq
2004-02-26 22:53 ` 2.6.3 Oops when power-off via sys-rq Len Brown
@ 2004-02-27 1:14 ` Andrew Morton
2004-02-27 13:36 ` Alexander Y. Fomichev
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2004-02-27 1:14 UTC (permalink / raw)
To: Len Brown; +Cc: gluk, linux-kernel, rathamahata
Len Brown <len.brown@intel.com> wrote:
>
> Alexander,
> Please file an bug at bugzilla.kernel.org
> category: power management
> component: ACPI
We'll need this fix (at least). But I haven't tested it yet.
sysrq-o is supposed to power off the machine. But if it calls into ACPI (at
least) it does lots of sleepy things, so we best not do this from interrupt
context.
---
kernel/power/poweroff.c | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff -puN kernel/power/poweroff.c~poweroff-atomicity-fix kernel/power/poweroff.c
--- 25/kernel/power/poweroff.c~poweroff-atomicity-fix 2004-02-26 05:13:59.000000000 -0800
+++ 25-akpm/kernel/power/poweroff.c 2004-02-26 05:18:31.000000000 -0800
@@ -8,33 +8,33 @@
#include <linux/sysrq.h>
#include <linux/init.h>
#include <linux/pm.h>
+#include <linux/workqueue.h>
-
-/**
- * handle_poweroff - sysrq callback for power down
- * @key: key pressed (unused)
- * @pt_regs: register state (unused)
- * @kbd: keyboard state (unused)
- * @tty: tty involved (unused)
- *
+/*
* When the user hits Sys-Rq o to power down the machine this is the
* callback we use.
*/
-static void handle_poweroff (int key, struct pt_regs *pt_regs,
- struct tty_struct *tty)
+static void do_poweroff(void *dummy)
{
if (pm_power_off)
pm_power_off();
}
+static DECLARE_WORK(poweroff_work, do_poweroff, 0);
+
+static void handle_poweroff(int key, struct pt_regs *pt_regs,
+ struct tty_struct *tty)
+{
+ schedule_work(&poweroff_work);
+}
+
static struct sysrq_key_op sysrq_poweroff_op = {
.handler = handle_poweroff,
.help_msg = "powerOff",
.action_msg = "Power Off\n"
};
-
static int pm_sysrq_init(void)
{
register_sysrq_key('o', &sysrq_poweroff_op);
_
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.6.3 Oops when power-off via sys-rq
2004-02-27 1:14 ` Andrew Morton
@ 2004-02-27 13:36 ` Alexander Y. Fomichev
0 siblings, 0 replies; 4+ messages in thread
From: Alexander Y. Fomichev @ 2004-02-27 13:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: Len Brown, linux-kernel, rathamahata
On Friday 27 February 2004 04:14, Andrew Morton wrote:
> Len Brown <len.brown@intel.com> wrote:
> > Alexander,
> > Please file an bug at bugzilla.kernel.org
> > category: power management
> > component: ACPI
Well, it's now registered as Bug#: 2213
>
> We'll need this fix (at least). But I haven't tested it yet.
>
>
>
>
>
> sysrq-o is supposed to power off the machine. But if it calls into ACPI
> (at least) it does lots of sleepy things, so we best not do this from
> interrupt context.
>
>
> ---
>
> kernel/power/poweroff.c | 22 +++++++++++-----------
> 1 files changed, 11 insertions(+), 11 deletions(-)
>
> diff -puN kernel/power/poweroff.c~poweroff-atomicity-fix
> kernel/power/poweroff.c ---
> 25/kernel/power/poweroff.c~poweroff-atomicity-fix 2004-02-26
> 05:13:59.000000000 -0800 +++ 25-akpm/kernel/power/poweroff.c 2004-02-26
> 05:18:31.000000000 -0800 @@ -8,33 +8,33 @@
> #include <linux/sysrq.h>
> #include <linux/init.h>
> #include <linux/pm.h>
> +#include <linux/workqueue.h>
>
> -
> -/**
> - * handle_poweroff - sysrq callback for power down
> - * @key: key pressed (unused)
> - * @pt_regs: register state (unused)
> - * @kbd: keyboard state (unused)
> - * @tty: tty involved (unused)
> - *
> +/*
> * When the user hits Sys-Rq o to power down the machine this is the
> * callback we use.
> */
>
> -static void handle_poweroff (int key, struct pt_regs *pt_regs,
> - struct tty_struct *tty)
> +static void do_poweroff(void *dummy)
> {
> if (pm_power_off)
> pm_power_off();
> }
>
> +static DECLARE_WORK(poweroff_work, do_poweroff, 0);
> +
> +static void handle_poweroff(int key, struct pt_regs *pt_regs,
> + struct tty_struct *tty)
> +{
> + schedule_work(&poweroff_work);
> +}
> +
> static struct sysrq_key_op sysrq_poweroff_op = {
> .handler = handle_poweroff,
> .help_msg = "powerOff",
> .action_msg = "Power Off\n"
> };
>
> -
> static int pm_sysrq_init(void)
> {
> register_sysrq_key('o', &sysrq_poweroff_op);
>
> _
Works pretty well for me,
thank you wery mach.
--
Best regards.
Alexander Y. Fomichev <gluk@php4.ru>
Public PGP key: http://sysadminday.org.ru/gluk.asc
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-02-27 13:37 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <A6974D8E5F98D511BB910002A50A6647615F3396@hdsmsx402.hd.intel.com>
2004-02-26 22:53 ` 2.6.3 Oops when power-off via sys-rq Len Brown
2004-02-27 1:14 ` Andrew Morton
2004-02-27 13:36 ` Alexander Y. Fomichev
2004-02-26 12:52 Alexander Y. Fomichev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox