When kernel halt's will reboot_mutex lock still hold at exit.
It will issue with 'halt' command:
$ halt
..
Sent SIGKILL to all processes
Requesting system halt
[66.729373] System halted.
[66.733244]
[66.734761] =====================================
[66.739473] [ BUG: lock held at task exit time! ]
[66.744188] 3.8.7-0-sampleversion-fct #49 Tainted: G O
[66.750202] -------------------------------------
[66.754913] init/21479 is exiting with locks still held!
[66.760234] 1 lock held by init/21479:
[66.763990] #0: (reboot_mutex){+.+...}, at: [<ffffffff801776c8>] SyS_reboot+0xe0/0x218
[66.772165]
[66.772165] stack backtrace:
[66.776532] Call Trace:
[66.778992] [<ffffffff805780a8>] dump_stack+0x8/0x34
[66.783972] [<ffffffff801618b0>] do_exit+0x610/0xa70
[66.788948] [<ffffffff801777a8>] SyS_reboot+0x1c0/0x218
[66.794186] [<ffffffff8013d6a4>] handle_sys64+0x44/0x64
With this commit we will still have a proper halt sequence
and the reboot_mutex held bug is gone: (added printk's to affected functions)
$ halt
..
ent SIGKILL to all processes
Requesting system halt
[70.258665] DBG: kernel/sys.c, 486, SYSC_reboot: (case LINUX_REBOOT_CMD_HALT:)
[70.268953] DBG: kernel/sys.c, 396, kernel_halt: (kernel_shutdown_prepare(..);)
[70.284069] DBG: kernel/sys.c, 398, kernel_halt: (syscore_shutdown();)
[70.294364] DBG: kernel/sys.c, 400, kernel_halt: (kmsg_dump(KMSG_DUMP_HALT);)
[70.304640] System halted.
[70.307363] DBG: kernel/sys.c, 403, kernel_halt: (machine_halt();)
[70.317640] DBG: arch/mips/cavium-octeon/setup.c, 502, octeon_halt:
[70.329582] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core1)
[70.329588] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core2)
[70.329594] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core3)
[70.329600] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core4)
[70.329607] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core5)
[70.329614] DBG: arch/mips/cavium-octeon/setup.c, 485, octeon_kill_core: (core6)
In this case on a 6 Core Cavium Octeon board.
Acked-by: Maxim Uvarov <[email protected]>
Signed-off-by: Wladislav Wiebe <[email protected]>
---
arch/mips/cavium-octeon/setup.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index b0baa29..04ce396 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -457,6 +457,10 @@ static void octeon_halt(void)
}
octeon_kill_core(NULL);
+
+ /* We stop here */
+ while (1)
+ ;
}
/**
--
1.7.9.5
On 05/23/2013 02:21 AM, Wladislav Wiebe wrote:
> When kernel halt's will reboot_mutex lock still hold at exit.
> It will issue with 'halt' command:
> $ halt
> ..
> Sent SIGKILL to all processes
> Requesting system halt
> [66.729373] System halted.
> [66.733244]
> [66.734761] =====================================
> [66.739473] [ BUG: lock held at task exit time! ]
> [66.744188] 3.8.7-0-sampleversion-fct #49 Tainted: G O
> [66.750202] -------------------------------------
> [66.754913] init/21479 is exiting with locks still held!
> [66.760234] 1 lock held by init/21479:
> [66.763990] #0: (reboot_mutex){+.+...}, at: [<ffffffff801776c8>] SyS_reboot+0xe0/0x218
> [66.772165]
> [66.772165] stack backtrace:
> [66.776532] Call Trace:
> [66.778992] [<ffffffff805780a8>] dump_stack+0x8/0x34
> [66.783972] [<ffffffff801618b0>] do_exit+0x610/0xa70
> [66.788948] [<ffffffff801777a8>] SyS_reboot+0x1c0/0x218
> [66.794186] [<ffffffff8013d6a4>] handle_sys64+0x44/0x64
>
>
[...]
>
> Acked-by: Maxim Uvarov <[email protected]>
> Signed-off-by: Wladislav Wiebe <[email protected]>
> ---
> arch/mips/cavium-octeon/setup.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
> index b0baa29..04ce396 100644
> --- a/arch/mips/cavium-octeon/setup.c
> +++ b/arch/mips/cavium-octeon/setup.c
> @@ -457,6 +457,10 @@ static void octeon_halt(void)
> }
>
> octeon_kill_core(NULL);
> +
> + /* We stop here */
> + while (1)
> + ;
I want to put a WAIT here so we don't burn so much power.
I will send a patch to do that instead.
> }
>
> /**
>
Sorry for the late reply - this ended up in the moderator queue for the
mailing list and I rarely look at it - it's tens of thousands of emails!
On Thu, May 23, 2013 at 11:58:34PM +0400, Maxim Uvarov wrote:
> >> diff --git a/arch/mips/cavium-octeon/**setup.c b/arch/mips/cavium-octeon/
> >> **setup.c
> >> index b0baa29..04ce396 100644
> >> --- a/arch/mips/cavium-octeon/**setup.c
> >> +++ b/arch/mips/cavium-octeon/**setup.c
> >> @@ -457,6 +457,10 @@ static void octeon_halt(void)
> >> }
> >>
> >> octeon_kill_core(NULL);
> >> +
> >> + /* We stop here */
> >> + while (1)
> >> + ;
> >>
> >
> > I want to put a WAIT here so we don't burn so much power.
> >
> > I will send a patch to do that instead.
> >
> >
> what about adding wait for other mips boards where is while (1) is used?
Many platforms have their own variants of eternal loops, some using
just "while (1);", others trying to save power using the WAIT instruction.
I was planing to work through all of them and come up with a common
defaut implementation.
Ralf