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: >> 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. >
Hi,Russell King 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
