Is Pandaboard cpuhotplug working stably?

[santosh.shilimkar@ti.com (Shilimkar, Santosh)]

On Thu, Dec 22, 2011 at 3:54 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Dec 22, 2011 at 02:19:23PM +0530, Shilimkar, Santosh wrote:
>> + Peter Z
>>
>> On Wed, Dec 21, 2011 at 3:37 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Wed, Dec 21, 2011 at 05:59:07PM +0800, Barry Song wrote:
>> >> 2011/12/21 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> >> > cpu hotplug is basically totally buggered - the preconditions placed
>> >> > upon the bringup code path are basically impossible to satisfy in any
>> >> > shape or form at the moment.
>> >> >
>> >> > There's the requirement that the secondary CPU is marked online and
>> >> > active before interrupts are enabled for the thread migration stuff
>> >> > to behave correctly. ?However, this is incompatible with smp_call_function()
>> >> > which will wait for online CPUs to respond to an IPI - which this one
>> >> > won't because interrupts are disabled.
>> >> >
>> >> > I think there was some discussion about how to fix this but I don't
>> >> > recall the details.
>> >>
>> >> thanks, Russell. then could i think this is an ARM-kernel-specific bug
>> >> which exists on all ARM SMP chips for the moment?
>> >> and that bug doesn't happen on x86:
>> >
>> > I don't think so. ?There's nothing ARM specific about it.
>>
>> There are few patches floating around for this issue. I posted one version
>> long back [1] and then there was one more form Thomas G.
>> The most recent is from one is from Peter Z [2] which is moving the
>> fix for the cup online race to core code.
>>
>> Can you try Peter's patch with your test-case ?
>>
>> Regards,
>> Santosh
>>
>> [1] https://lkml.org/lkml/2011/6/20/79
>> [2] https://lkml.org/lkml/2011/12/15/255
>
> [1] is already fixed - and is not the latest "problem" with this code.
> Fixing the problem in [1] actually itself created the latest problem
> with smp_call_function() which wasn't there before this change. ?Patch
> [2] refers to this problem and proposes a fix for it.

Thanks Russell for information. Looks like I missed in between thread.

Regards
Santosh