[SMP BUG?] the return value of is_smp() is bug?
long.wanglong at huawei.com
Wed Sep 3 18:01:41 PDT 2014
On 2014/9/1 18:19, Russell King - ARM Linux wrote:
> 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:
>> 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/
> 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.
Thank you for your reply. I will not send multiple copies of message to mailing lists.
The problem is that qemu doesn't provide emulation of the SCU base address register.
More information about the linux-arm-kernel