[SMP BUG?] the return value of is_smp() is bug?

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

Firstly, do not send multiple copies of your message to mailing lists,
certainly not within the three hours that you sent your three copies.
If one of the addresses you sent the message to bounces, then it is
*only* that one recipient who doesn't get your message, everyone else
receives a copy.  So, there's now three copies of your message in the
list archives, and people could end up replying to different messages.

On Mon, Sep 01, 2014 at 07:35:34PM +0800, Wang Long wrote:
> Hi,all
> 
> In kernel 3.17-rc2, when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y 
> in .config file. the secondary core can not boot.
> 
> when i set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = n in .config file,
> the secondary core can boot.
> 
> But this does not happen in kernel 3.10 lts kernel, Whether the 
> CONFIG_SMP_ON_UP is set yes or no ,the secondary core can boot.
> 
> Does the meaning of CONFIG_SMP_ON_UP changed or this is a bug in kernel 3.17-rc2 ? 

I think the answer is neither, because when the kernel is run on /real/
hardware:

http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=2514

it boots fine, bringing up all four CPUs.

> config:     set CONFIG_HAVE_SMP = y and CONFIG_SMP_ON_UP = y
> command:    # qemu-system-arm -M vexpress-a9 -smp 2  -m 128M -kernel arch/arm/boot/zImage -nographic

I've no idea how qemu works here, but if the CPU doesn't indicate that
it's a SMP capable CPU, we will disable SMP extensions.

> The output:
> 
> ..........
> is_smp() return false;
> CPU: Testing write buffer coherency: ok
> missing device node for CPU 0
> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> Setting up static identity map for 0x604643d8 - 0x60464430
> Brought up 1 CPUs
> SMP: Total of 1 processors activated.
> CPU: All CPU(s) started in SVC mode.
> ...........

You have decided that you'll edit the kernel messages, removing at least
some of the information that could be relevant to the issue.  Please,
only cut kernel messages when you are absolutely certain that they are
not relevant to the problem you're reporting.

However, I don't think it would help much - I suspect that qemu doesn't
provide emulation of the SCU base address register, and that's what your
problem is.  qemu needs to be fixed in that regard.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.