* [PATCH v2 1/1] MIPS: Octeon: fix for held reboot_mutex lock at task exit time
@ 2013-05-23 9:21 Wladislav Wiebe
2013-05-23 17:05 ` David Daney
0 siblings, 1 reply; 4+ messages in thread
From: Wladislav Wiebe @ 2013-05-23 9:21 UTC (permalink / raw)
To: Ralf Baechle, david.daney, Maxim Uvarov, davem; +Cc: linux-mips, linux-kernel
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 <muvarov@gmail.com>
Signed-off-by: Wladislav Wiebe <wladislav.kw@gmail.com>
---
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
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2 1/1] MIPS: Octeon: fix for held reboot_mutex lock at task exit time
2013-05-23 9:21 [PATCH v2 1/1] MIPS: Octeon: fix for held reboot_mutex lock at task exit time Wladislav Wiebe
@ 2013-05-23 17:05 ` David Daney
2013-05-23 19:58 ` Maxim Uvarov
0 siblings, 1 reply; 4+ messages in thread
From: David Daney @ 2013-05-23 17:05 UTC (permalink / raw)
To: Wladislav Wiebe
Cc: Ralf Baechle, david.daney, Maxim Uvarov, davem, linux-mips,
linux-kernel
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 <muvarov@gmail.com>
> Signed-off-by: Wladislav Wiebe <wladislav.kw@gmail.com>
> ---
> 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.
> }
>
> /**
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2 1/1] MIPS: Octeon: fix for held reboot_mutex lock at task exit time
2013-05-23 17:05 ` David Daney
@ 2013-05-23 19:58 ` Maxim Uvarov
2013-06-28 10:45 ` Ralf Baechle
0 siblings, 1 reply; 4+ messages in thread
From: Maxim Uvarov @ 2013-05-23 19:58 UTC (permalink / raw)
To: David Daney
Cc: Wladislav Wiebe, Ralf Baechle, david.daney, davem, linux-mips,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
2013/5/23 David Daney <ddaney.cavm@gmail.com>
> 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 <muvarov@gmail.com>
>> Signed-off-by: Wladislav Wiebe <wladislav.kw@gmail.com>
>> ---
>> 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.
>
>
what about adding wait for other mips boards where is while (1) is used?
Maxim.
> }
>>
>> /**
>>
>>
>
--
Best regards,
Maxim Uvarov
[-- Attachment #2: Type: text/html, Size: 3103 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2 1/1] MIPS: Octeon: fix for held reboot_mutex lock at task exit time
2013-05-23 19:58 ` Maxim Uvarov
@ 2013-06-28 10:45 ` Ralf Baechle
0 siblings, 0 replies; 4+ messages in thread
From: Ralf Baechle @ 2013-06-28 10:45 UTC (permalink / raw)
To: Maxim Uvarov
Cc: David Daney, Wladislav Wiebe, david.daney, davem, linux-mips,
linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-06-28 10:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-23 9:21 [PATCH v2 1/1] MIPS: Octeon: fix for held reboot_mutex lock at task exit time Wladislav Wiebe
2013-05-23 17:05 ` David Daney
2013-05-23 19:58 ` Maxim Uvarov
2013-06-28 10:45 ` Ralf Baechle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.