ARM: only call smp_send_stop() on SMP

PATCH New Javier Martinez Canillas 6 participants 16 messages Jun 24, 2012 – Jul 30, 2012 Arm (32-bit)

Share & tools

Javier Martinez Canillas

author

2012-06-24 10:28 UTC #0 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

On reboot or poweroff (machine_shutdown()) a call to smp_send_stop() is made (to stop the others CPU's) when CONFIG_SMP=y.

arch/arm/kernel/process.c:

void machine_shutdown(void)
{

 #ifdef CONFIG_SMP
       smp_send_stop();

#endif
}

smp_send_stop() calls the function pointer smp_cross_call(), which is set on the smp_init_cpus() function for OMAP processors.

arch/arm/mach-omap2/omap-smp.c:

void __init smp_init_cpus(void)
{
...

	set_smp_cross_call(gic_raise_softirq);

...
}

But the ARM setup_arch() function only calls smp_init_cpus() if CONFIG_SMP=y && is_smp().

arm/kernel/setup.c:

void __init setup_arch(char **cmdline_p)
{
...

 #ifdef CONFIG_SMP
	if (is_smp())
		smp_init_cpus();

#endif
...
}

Newer OMAP CPU's are SMP machines so omap2plus_defconfig sets CONFIG_SMP=y. Unfortunately on an OMAP UP machine is_smp() returns false and smp_init_cpus() is never called and the smp_cross_call() function remains NULL.

If the machine is rebooted or powered off, smp_send_stop() will be called (since CONFIG_SMP=y) leading to the following error:

[   42.815551] Restarting system.
[   42.819030] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   42.827667] pgd = d7a74000
[   42.830566] [00000000] *pgd=96ce7831, *pte=00000000, *ppte=00000000
[   42.837249] Internal error: Oops: 80000007 [#1] SMP ARM
[   42.842773] Modules linked in:
[   42.846008] CPU: 0    Not tainted  (3.5.0-rc3-next-20120622-00002-g62e87ba-dirty #44)
[   42.854278] PC is at 0x0
[   42.856994] LR is at smp_send_stop+0x4c/0xe4
[   42.861511] pc : [<00000000>]    lr : [<c00183a4>]    psr: 60000013
[   42.861511] sp : d6c85e70  ip : 00000000  fp : 00000000
[   42.873626] r10: 00000000  r9 : d6c84000  r8 : 00000002
[   42.879150] r7 : c07235a0  r6 : c06dd2d0  r5 : 000f4241  r4 : d6c85e74
[   42.886047] r3 : 00000000  r2 : 00000000  r1 : 00000006  r0 : d6c85e74
[   42.892944] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   42.900482] Control: 10c5387d  Table: 97a74019  DAC: 00000015
[   42.906555] Process reboot (pid: 1166, stack limit = 0xd6c842f8)
[   42.912902] Stack: (0xd6c85e70 to 0xd6c86000)
[   42.917510] 5e60:                                     c07235a0 00000000 00000000 d6c84000
[   42.926177] 5e80: 01234567 c00143d0 4321fedc c00511bc d6c85ebc 00000168 00000460 00000000
[   42.934814] 5ea0: c1017950 a0000013 c1017900 d8014390 d7ec3858 c0498e48 c1017950 00000000
[   42.943481] 5ec0: d6ddde10 d6c85f78 00000003 00000000 d6ddde10 d6c84000 00000000 00000000
[   42.952117] 5ee0: 00000002 00000000 00000000 c0088c88 00000002 00000000 00000000 c00f4b90
[   42.960784] 5f00: 00000000 d6c85ebc d8014390 d7e311c8 60000013 00000103 00000002 d6c84000
[   42.969421] 5f20: c00f3274 d6e00a00 00000001 60000013 d6c84000 00000000 00000000 c00895d4
[   42.978057] 5f40: 00000002 d8007c80 d781f000 c00f6150 d8010cc0 c00f3274 d781f000 d6c84000
[   42.986694] 5f60: c0013020 d6e00a00 00000001 20000010 0001257c ef000000 00000000 c00895d4
[   42.995361] 5f80: 00000002 00000001 00000003 00000000 00000001 00000003 00000000 00000058
[   43.003997] 5fa0: c00130c8 c0012f00 00000001 00000003 fee1dead 28121969 01234567 00000002
[   43.012634] 5fc0: 00000001 00000003 00000000 00000058 00012584 0001257c 00000001 00000000
[   43.021270] 5fe0: 000124bc bec5cc6c 00008f9c 4a2f7c40 20000010 fee1dead 00000000 00000000
[   43.029968] [<c00183a4>] (smp_send_stop+0x4c/0xe4) from [<c00143d0>] (machine_restart+0xc/0x4c)
[   43.039154] [<c00143d0>] (machine_restart+0xc/0x4c) from [<c00511bc>] (sys_reboot+0x144/0x1f0)
[   43.048278] [<c00511bc>] (sys_reboot+0x144/0x1f0) from [<c0012f00>] (ret_fast_syscall+0x0/0x3c)
[   43.057464] Code: bad PC value
[   43.060760] ---[ end trace c3988d1dd0b8f0fb ]---

Add a check so smp_cross_call() is only called when there is more than one CPU on-line.

Signed-off-by Javier Martinez Canillas <[email protected]>

---

Changes since v1:

- check for cpumask_empty() on arch/arm/kernel/smp.c instead for is_smp() on arch/arm/kernel/process.c

 arch/arm/kernel/smp.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

arch/arm/kernel/smp.c +2 -1

index 2c7217d..ea73045 100644
@@ -563,7 +563,8 @@ void smp_send_stop(void)
 
 	cpumask_copy(&mask, cpu_online_mask);
 	cpumask_clear_cpu(smp_processor_id(), &mask);
-	smp_cross_call(&mask, IPI_CPU_STOP);
+	if (!cpumask_empty(&mask))
+		smp_cross_call(&mask, IPI_CPU_STOP);
 
 	/* Wait up to one second for other CPUs to stop */
 	timeout = USEC_PER_SEC;

Signature · 1 line

1.7.7.6

Shawn Guo

2012-06-25 00:51 UTC #1 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

It seems the same patch has been there for a while.

http://thread.gmane.org/gmane.linux.kernel/1303115

Regards,
Shawn

Quoted 119 lines · Javier Martinez Canillas

On reboot or poweroff (machine_shutdown()) a call to smp_send_stop() is made (to stop the others CPU's) when CONFIG_SMP=y.

arch/arm/kernel/process.c:

void machine_shutdown(void)
{

 #ifdef CONFIG_SMP
       smp_send_stop();

#endif
}

smp_send_stop() calls the function pointer smp_cross_call(), which is set on the smp_init_cpus() function for OMAP processors.

arch/arm/mach-omap2/omap-smp.c:

void __init smp_init_cpus(void)
{
...

	set_smp_cross_call(gic_raise_softirq);

...
}

But the ARM setup_arch() function only calls smp_init_cpus() if CONFIG_SMP=y && is_smp().

arm/kernel/setup.c:

void __init setup_arch(char **cmdline_p)
{
...

 #ifdef CONFIG_SMP
	if (is_smp())
		smp_init_cpus();

#endif
...
}

If the machine is rebooted or powered off, smp_send_stop() will be called (since CONFIG_SMP=y) leading to the following error:

[   42.815551] Restarting system.
[   42.819030] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   42.827667] pgd = d7a74000
[   42.830566] [00000000] *pgd=96ce7831, *pte=00000000, *ppte=00000000
[   42.837249] Internal error: Oops: 80000007 [#1] SMP ARM
[   42.842773] Modules linked in:
[   42.846008] CPU: 0    Not tainted  (3.5.0-rc3-next-20120622-00002-g62e87ba-dirty #44)
[   42.854278] PC is at 0x0
[   42.856994] LR is at smp_send_stop+0x4c/0xe4
[   42.861511] pc : [<00000000>]    lr : [<c00183a4>]    psr: 60000013
[   42.861511] sp : d6c85e70  ip : 00000000  fp : 00000000
[   42.873626] r10: 00000000  r9 : d6c84000  r8 : 00000002
[   42.879150] r7 : c07235a0  r6 : c06dd2d0  r5 : 000f4241  r4 : d6c85e74
[   42.886047] r3 : 00000000  r2 : 00000000  r1 : 00000006  r0 : d6c85e74
[   42.892944] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   42.900482] Control: 10c5387d  Table: 97a74019  DAC: 00000015
[   42.906555] Process reboot (pid: 1166, stack limit = 0xd6c842f8)
[   42.912902] Stack: (0xd6c85e70 to 0xd6c86000)
[   42.917510] 5e60:                                     c07235a0 00000000 00000000 d6c84000
[   42.926177] 5e80: 01234567 c00143d0 4321fedc c00511bc d6c85ebc 00000168 00000460 00000000
[   42.934814] 5ea0: c1017950 a0000013 c1017900 d8014390 d7ec3858 c0498e48 c1017950 00000000
[   42.943481] 5ec0: d6ddde10 d6c85f78 00000003 00000000 d6ddde10 d6c84000 00000000 00000000
[   42.952117] 5ee0: 00000002 00000000 00000000 c0088c88 00000002 00000000 00000000 c00f4b90
[   42.960784] 5f00: 00000000 d6c85ebc d8014390 d7e311c8 60000013 00000103 00000002 d6c84000
[   42.969421] 5f20: c00f3274 d6e00a00 00000001 60000013 d6c84000 00000000 00000000 c00895d4
[   42.978057] 5f40: 00000002 d8007c80 d781f000 c00f6150 d8010cc0 c00f3274 d781f000 d6c84000
[   42.986694] 5f60: c0013020 d6e00a00 00000001 20000010 0001257c ef000000 00000000 c00895d4
[   42.995361] 5f80: 00000002 00000001 00000003 00000000 00000001 00000003 00000000 00000058
[   43.003997] 5fa0: c00130c8 c0012f00 00000001 00000003 fee1dead 28121969 01234567 00000002
[   43.012634] 5fc0: 00000001 00000003 00000000 00000058 00012584 0001257c 00000001 00000000
[   43.021270] 5fe0: 000124bc bec5cc6c 00008f9c 4a2f7c40 20000010 fee1dead 00000000 00000000
[   43.029968] [<c00183a4>] (smp_send_stop+0x4c/0xe4) from [<c00143d0>] (machine_restart+0xc/0x4c)
[   43.039154] [<c00143d0>] (machine_restart+0xc/0x4c) from [<c00511bc>] (sys_reboot+0x144/0x1f0)
[   43.048278] [<c00511bc>] (sys_reboot+0x144/0x1f0) from [<c0012f00>] (ret_fast_syscall+0x0/0x3c)
[   43.057464] Code: bad PC value
[   43.060760] ---[ end trace c3988d1dd0b8f0fb ]---

Add a check so smp_cross_call() is only called when there is more than one CPU on-line.

Signed-off-by Javier Martinez Canillas <[email protected]>

---

Changes since v1:

- check for cpumask_empty() on arch/arm/kernel/smp.c instead for is_smp() on arch/arm/kernel/process.c

 arch/arm/kernel/smp.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

arch/arm/kernel/smp.c +2 -1

index 2c7217d..ea73045 100644
@@ -563,7 +563,8 @@ void smp_send_stop(void)
 
 	cpumask_copy(&mask, cpu_online_mask);
 	cpumask_clear_cpu(smp_processor_id(), &mask);
-	smp_cross_call(&mask, IPI_CPU_STOP);
+	if (!cpumask_empty(&mask))
+		smp_cross_call(&mask, IPI_CPU_STOP);
 
 	/* Wait up to one second for other CPUs to stop */
 	timeout = USEC_PER_SEC;

Signature · 7 lines

1.7.7.6


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Javier Martinez Canillas

2012-06-25 08:09 UTC #2 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Quoted 7 lines · Shawn Guo

It seems the same patch has been there for a while.
http://thread.gmane.org/gmane.linux.kernel/1303115
Regards,
Shawn

Hi Shawn,

Thanks for the info, I first send this patch:
http://www.spinics.net/lists/linux-omap/msg72489.html but Russell pointed me to the thread:
http://lists.arm.linux.org.uk/lurker/thread/20120523.200015.2fdfd505.en.html
and told me that no patch ever came from his response on the subject. That's why I sent this patch with Russell suggested approach to solve the issue. But as you said, it was sent but got lost.

That's a pity since the bug is pretty serious (it deterministically crashes when trying to reboot the board).

Thanks a lot and best regards,
Javier

Russell King - ARM Linux

2012-06-25 08:49 UTC #3 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

In reply to Shawn Guo

Quoted 3 lines · Shawn Guo

It seems the same patch has been there for a while.
http://thread.gmane.org/gmane.linux.kernel/1303115

Bah, why doesn't stuff like this get resent if nothing has happened for a while?

Javier Martinez Canillas

2012-06-25 10:31 UTC #4 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Quoted 7 lines · Russell King - ARM Linux

Quoted 3 lines · Shawn Guo
It seems the same patch has been there for a while.
http://thread.gmane.org/gmane.linux.kernel/1303115
Bah, why doesn't stuff like this get resent if nothing has happened for a while?

Indeed. At least other people that face the same issue (like me) sends similar patches to remind you :-)

Best regards,
Javier

Jon Hunter

2012-07-27 17:15 UTC #5 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Hi Javier,

Quoted 5 lines · Javier Martinez Canillas

Quoted 3 lines · Russell King - ARM Linux
Quoted 2 lines · Shawn Guo
It seems the same patch has been there for a while.

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
http://thread.gmane.org/gmane.linux.kernel/1303115
Bah, why doesn't stuff like this get resent if nothing has happened for a while?
Indeed. At least other people that face the same issue (like me) sends similar patches to remind you :-)

I checked with Russell but this one is not in his patch tracking system
[1] and so still not queued. Can you submit this? Would be great to get this one in.

Cheers
Jon

[1] http://www.arm.linux.org.uk/developer/patches/

Will Deacon

2012-07-27 20:44 UTC #6 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Quoted 13 lines · Jon Hunter

Hi Javier,
Quoted 10 lines · Javier Martinez Canillas
Quoted 7 lines · Russell King - ARM Linux
Quoted 3 lines · Shawn Guo
It seems the same patch has been there for a while.
http://thread.gmane.org/gmane.linux.kernel/1303115
Bah, why doesn't stuff like this get resent if nothing has happened for a while?

Quoted 6 lines

Quoted 2 lines
Indeed. At least other people that face the same issue (like me) sends similar patches to remind you :-)
I checked with Russell but this one is not in his patch tracking system
[1] and so still not queued. Can you submit this? Would be great to get this one in.

I did comment on this one:

http://thread.gmane.org/gmane.linux.kernel/1303115

and I really think we should fix the cause of the problem, rather than point patching this instance of it.

Will

Russell King - ARM Linux

2012-07-27 21:06 UTC #7 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Quoted 21 lines · Will Deacon

Quoted 13 lines · Jon Hunter
Hi Javier,
Quoted 10 lines · Javier Martinez Canillas
Quoted 7 lines · Russell King - ARM Linux
Quoted 3 lines · Shawn Guo
It seems the same patch has been there for a while.
http://thread.gmane.org/gmane.linux.kernel/1303115
Bah, why doesn't stuff like this get resent if nothing has happened for a while?
Quoted 6 lines
Quoted 2 lines
Indeed. At least other people that face the same issue (like me) sends similar patches to remind you :-)
I checked with Russell but this one is not in his patch tracking system
[1] and so still not queued. Can you submit this? Would be great to get this one in.

Quoted 6 lines

I did comment on this one:
http://thread.gmane.org/gmane.linux.kernel/1303115
and I really think we should fix the cause of the problem, rather than point patching this instance of it.

What do you think needs fixing there?

We support booting a kernel on systems with or without SMP support, even with a SMP kernel. When the kernel is booted on such a system, it is undefined whether smp_cross_call() is a valid function pointer.

In any case, when we have only one CPU online in the system, it is pointless even calling smp_cross_call().

That is why I explicitly suggested this solution. This is the solution _I_ want, because it is the most sane solution all round.

Will Deacon

2012-07-27 21:40 UTC #8 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Hi Russell,

Quoted 9 lines · Russell King - ARM Linux

Quoted 6 lines · Will Deacon
I did comment on this one:
http://thread.gmane.org/gmane.linux.kernel/1303115
and I really think we should fix the cause of the problem, rather than point patching this instance of it.
What do you think needs fixing there?

Well, we certainly need to fix the NULL dereference and the original patch does do that. I just think it might be nicer to remove the possibility of a NULL dereference instead.

Quoted 3 lines

We support booting a kernel on systems with or without SMP support, even with a SMP kernel. When the kernel is booted on such a system, it is undefined whether smp_cross_call() is a valid function pointer.

So let's define it to point at a dummy function which explodes with a BUG if the cpumask passed in isn't empty. That allows SMP kernels to do things like `cross call to all other cores' without having to worry about whether there are any other cores or not.

Quoted 2 lines

In any case, when we have only one CPU online in the system, it is pointless even calling smp_cross_call().

Pointless, but also error-prone and requiring explicit cpumask checks at each call-site.

Quoted 2 lines

That is why I explicitly suggested this solution. This is the solution _I_ want, because it is the most sane solution all round.

Adding a dummy implementation is straightforward [ok, this is untested]:

arch/arm/kernel/smp.c +7 -1

index 2c7217d..ffa411f 100644
@@ -329,7 +329,13 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
        }
 }
 
-static void (*smp_cross_call)(const struct cpumask *, unsigned int);
+static void dummy_smp_cross_call(const struct cpumask *mask, unsigned int irq)
+{
+       BUG_ON(!cpumask_empty(mask));
+}
+
+static void (*smp_cross_call)(const struct cpumask *, unsigned int) =
+       dummy_smp_cross_call;
 
 void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int))
 {

If you still prefer checking at the call-site then the original patch will certainly work. Otherwise, I'm happy to submit the above after some testing.

Will

Russell King - ARM Linux

2012-07-28 10:08 UTC #9 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Quoted 9 lines · Will Deacon

Quoted 3 lines · Russell King - ARM Linux
We support booting a kernel on systems with or without SMP support, even with a SMP kernel. When the kernel is booted on such a system, it is undefined whether smp_cross_call() is a valid function pointer.
So let's define it to point at a dummy function which explodes with a BUG if the cpumask passed in isn't empty. That allows SMP kernels to do things like `cross call to all other cores' without having to worry about whether there are any other cores or not.

We should not be even attempting to do any cross calls when there aren't any other CPUs in the system - that's rather the point of leaving it as a NULL pointer so it does explode on such systems.

. the scheduler won't call smp_send_reschedule() when there are no other
CPUs in the system.
. timer ticks won't be broadcast to other CPUs if there are no other CPUs
in the system.
. function calls will not be issued to other CPUs if there are no other
CPUs in the system.

There is only one case where this doesn't happen, and that's the shutdown path.

For instance, smp_call_function*() all check that the target CPUs are marked online before the arch code is requested to issue an IPI to the target CPU.

The only place which is missing this check is smp_send_stop().

Now, we could make machine_shutdown() do this instead:

	if (is_smp())
		smp_send_stop();

but why bother calling into smp_send_stop(), and ultimately end up with the _only_ site which calls smp_cross_call() with an empty CPU mask when we can avoid the call when the CPU mask is empty - and prevent this special case of smp_cross_call() being called with an empty CPU mask ever occuring.

Will Deacon

2012-07-28 12:11 UTC #10 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Quoted 22 lines · Russell King - ARM Linux

Quoted 9 lines · Will Deacon
Quoted 3 lines · Russell King - ARM Linux
We support booting a kernel on systems with or without SMP support, even with a SMP kernel. When the kernel is booted on such a system, it is undefined whether smp_cross_call() is a valid function pointer.
So let's define it to point at a dummy function which explodes with a BUG if the cpumask passed in isn't empty. That allows SMP kernels to do things like `cross call to all other cores' without having to worry about whether there are any other cores or not.
We should not be even attempting to do any cross calls when there aren't any other CPUs in the system - that's rather the point of leaving it as a NULL pointer so it does explode on such systems.
. the scheduler won't call smp_send_reschedule() when there are no other
CPUs in the system.
. timer ticks won't be broadcast to other CPUs if there are no other CPUs
in the system.
. function calls will not be issued to other CPUs if there are no other
CPUs in the system.

Quoted 2 lines

There is only one case where this doesn't happen, and that's the shutdown path.

Ok, that's a pretty compelling argument you've got there :)

Quoted 3 lines

For instance, smp_call_function*() all check that the target CPUs are marked online before the arch code is requested to issue an IPI to the target CPU.

Yes, thanks for making the case for the original patch. Consistency is the most important thing with these APIs, so I'll go full circle and offer my ack for the original patch:

Acked-by Will Deacon <[email protected]>

The next question is: who's putting this into the patch system?

Will

Javier Martinez Canillas

author

2012-07-28 14:26 UTC #11 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Quoted 36 lines · Will Deacon

Quoted 22 lines · Russell King - ARM Linux
Quoted 9 lines · Will Deacon
Quoted 3 lines · Russell King - ARM Linux
We support booting a kernel on systems with or without SMP support, even with a SMP kernel. When the kernel is booted on such a system, it is undefined whether smp_cross_call() is a valid function pointer.
So let's define it to point at a dummy function which explodes with a BUG if the cpumask passed in isn't empty. That allows SMP kernels to do things like `cross call to all other cores' without having to worry about whether there are any other cores or not.
We should not be even attempting to do any cross calls when there aren't any other CPUs in the system - that's rather the point of leaving it as a NULL pointer so it does explode on such systems.
. the scheduler won't call smp_send_reschedule() when there are no other
CPUs in the system.
. timer ticks won't be broadcast to other CPUs if there are no other CPUs
in the system.
. function calls will not be issued to other CPUs if there are no other
CPUs in the system.
Quoted 2 lines
There is only one case where this doesn't happen, and that's the shutdown path.
Ok, that's a pretty compelling argument you've got there :)
Quoted 3 lines
For instance, smp_call_function*() all check that the target CPUs are marked online before the arch code is requested to issue an IPI to the target CPU.
Yes, thanks for making the case for the original patch. Consistency is the most important thing with these APIs, so I'll go full circle and offer my ack for the original patch:

Quoted 5 lines

Acked-by Will Deacon <[email protected]>
The next question is: who's putting this into the patch system?
Will

Hi,

I just put the patch with Will's Acked-by on the patch system. It was accepted as patch 7480/1 [1].

The patch is on top of today's linux-next (next-20120727).

Thanks a lot and best regards,
Javier

[1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7480/1

Russell King - ARM Linux

2012-07-29 21:31 UTC #12 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Quoted 12 lines · Javier Martinez Canillas

Quoted 5 lines · Will Deacon
Acked-by Will Deacon <[email protected]>
The next question is: who's putting this into the patch system?
Will
Hi,
I just put the patch with Will's Acked-by on the patch system. It was accepted as patch 7480/1 [1].

Quoted 6 lines

The patch is on top of today's linux-next (next-20120727).
Thanks a lot and best regards,
Javier
[1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7480/1

Isn't this a candidate for stable kernels?

Javier Martinez Canillas

author

2012-07-30 09:22 UTC #13 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Quoted 13 lines · Russell King - ARM Linux

Quoted 12 lines · Javier Martinez Canillas
Quoted 5 lines · Will Deacon
Acked-by Will Deacon <[email protected]>
The next question is: who's putting this into the patch system?
Will
Hi,
I just put the patch with Will's Acked-by on the patch system. It was accepted as patch 7480/1 [1].

Quoted 8 lines

Quoted 6 lines
The patch is on top of today's linux-next (next-20120727).
Thanks a lot and best regards,
Javier
[1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7480/1
Isn't this a candidate for stable kernels?

Yes, I forgot it, sorry for that.

Please let me know if I need to resubmit the patch cc'ing stable.

Best regards,
Javier

Russell King - ARM Linux

2012-07-30 14:35 UTC #14 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Quoted 3 lines · Javier Martinez Canillas

Yes, I forgot it, sorry for that.
Please let me know if I need to resubmit the patch cc'ing stable.

I can just add it to the commit.

Javier Martinez Canillas

author

2012-07-30 14:51 UTC #15 lore raw

PATCH v2 1/1 ARM: only call smp_send_stop() on SMP

Quoted 6 lines · Russell King - ARM Linux

Quoted 3 lines · Javier Martinez Canillas
Yes, I forgot it, sorry for that.
Please let me know if I need to resubmit the patch cc'ing stable.
I can just add it to the commit.

Perfect, thanks a lot and sorry for missing that.

Best regards,
Javier