All of lore.kernel.org
 help / color / mirror / Atom feed
From: long.wanglong@huawei.com (long.wanglong)
To: linux-arm-kernel@lists.infradead.org
Subject: [SMP BUG?] the return value of is_smp() is bug?
Date: Mon, 1 Sep 2014 18:00:58 +0800	[thread overview]
Message-ID: <540443DA.7030502@huawei.com> (raw)
In-Reply-To: <1409550563-92081-1-git-send-email-long.wanglong@huawei.com>

On 2014/9/1 13:49, 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 ? 
> 
> 

hi Arnd

In above two cases, i also set  CONFIG_SMP = y. in addtion,
the CONFIG_SMP_ON_UP depends on CONFIG_SMP. when set
CONFIG_SMP_ON_UP = y, the value of CONFIG_SMP must be y.



> I write the following patch to test the return value of is_smp().
> 
> ----------------------------------------
> 
> Signed-off-by: Wang Long <long.wanglong@huawei.com>
> ---
>  arch/arm/kernel/setup.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 84db893d..fbeb67f 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -925,6 +925,11 @@ void __init setup_arch(char **cmdline_p)
>  	arm_dt_init_cpu_maps();
>  	psci_init();
>  #ifdef CONFIG_SMP
> +	
> +	if (is_smp() == 1)
> +		printk("is_smp() return true;\n");
> +	else if (is_smp() == 0)
> +		printk("is_smp() return false;\n");
>  	if (is_smp()) {
>  		if (!mdesc->smp_init || !mdesc->smp_init()) {
>  			if (psci_smp_available())
> 
> kernel version: 3.17-rc2
> 
> 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
> 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.
> ...........
> 
> config:     set CONFIG_HAVE_SMP = y and not set CONFIG_SMP_ON_UP 
> command:    # qemu-system-arm -M vexpress-a9 -smp 2  -m 128M -kernel arch/arm/boot/zImage -nographic
> The output:
> 
> .....
>  Memory policy: Data cache writealloc
> is_smp() return true;
> sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
> ......
> ......
> CPU: Testing write buffer coherency: ok
> missing device node for CPU 0
> missing device node for CPU 1
> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> Setting up static identity map for 0x60463ef8 - 0x60463f50
> CPU1: Booted secondary processor
> CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
> Brought up 2 CPUs
> SMP: Total of 2 processors activated.
> CPU: All CPU(s) started in SVC mode.
> devtmpfs: initialized
> .......
> 
> Any ideas?
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: "long.wanglong" <long.wanglong@huawei.com>
To: Wang Long <long.wanglong@huawei.com>, <arnd@arndb.de>
Cc: <linux@arm.linux.org.uk>, <santosh.shilimkar@ti.com>,
	<victor.kamensky@linaro.org>, <nico@linaro.org>,
	<ben.dooks@codethink.co.uk>, <cov@codeaurora.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [SMP BUG?] the return value of is_smp() is bug?
Date: Mon, 1 Sep 2014 18:00:58 +0800	[thread overview]
Message-ID: <540443DA.7030502@huawei.com> (raw)
In-Reply-To: <1409550563-92081-1-git-send-email-long.wanglong@huawei.com>

On 2014/9/1 13:49, 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 ? 
> 
> 

hi Arnd

In above two cases, i also set  CONFIG_SMP = y. in addtion,
the CONFIG_SMP_ON_UP depends on CONFIG_SMP. when set
CONFIG_SMP_ON_UP = y, the value of CONFIG_SMP must be y.



> I write the following patch to test the return value of is_smp().
> 
> ----------------------------------------
> 
> Signed-off-by: Wang Long <long.wanglong@huawei.com>
> ---
>  arch/arm/kernel/setup.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 84db893d..fbeb67f 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -925,6 +925,11 @@ void __init setup_arch(char **cmdline_p)
>  	arm_dt_init_cpu_maps();
>  	psci_init();
>  #ifdef CONFIG_SMP
> +	
> +	if (is_smp() == 1)
> +		printk("is_smp() return true;\n");
> +	else if (is_smp() == 0)
> +		printk("is_smp() return false;\n");
>  	if (is_smp()) {
>  		if (!mdesc->smp_init || !mdesc->smp_init()) {
>  			if (psci_smp_available())
> 
> kernel version: 3.17-rc2
> 
> 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
> 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.
> ...........
> 
> config:     set CONFIG_HAVE_SMP = y and not set CONFIG_SMP_ON_UP 
> command:    # qemu-system-arm -M vexpress-a9 -smp 2  -m 128M -kernel arch/arm/boot/zImage -nographic
> The output:
> 
> .....
>  Memory policy: Data cache writealloc
> is_smp() return true;
> sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
> ......
> ......
> CPU: Testing write buffer coherency: ok
> missing device node for CPU 0
> missing device node for CPU 1
> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> Setting up static identity map for 0x60463ef8 - 0x60463f50
> CPU1: Booted secondary processor
> CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
> Brought up 2 CPUs
> SMP: Total of 2 processors activated.
> CPU: All CPU(s) started in SVC mode.
> devtmpfs: initialized
> .......
> 
> Any ideas?
> 
> 



  reply	other threads:[~2014-09-01 10:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-01  5:49 [SMP BUG?] the return value of is_smp() is bug? Wang Long
2014-09-01  5:49 ` Wang Long
2014-09-01 10:00 ` long.wanglong [this message]
2014-09-01 10:00   ` long.wanglong
2014-09-01 10:26   ` Arnd Bergmann
2014-09-01 10:26     ` Arnd Bergmann
2014-09-04  1:13     ` long.wanglong
2014-09-04  1:13       ` long.wanglong
2014-09-04  8:33       ` Peter Maydell
2014-09-04  8:33         ` Peter Maydell
  -- strict thread matches above, loose matches on Subject: below --
2014-09-01 11:15 Wang Long
2014-09-01 11:15 ` Wang Long
2014-09-02  4:40 ` Leon Yu
2014-09-01 11:35 Wang Long
2014-09-01 11:35 ` Wang Long
2014-09-01  8:49 ` Arnd Bergmann
2014-09-01  8:49   ` Arnd Bergmann
2014-09-01 10:19 ` Russell King - ARM Linux
2014-09-01 10:19   ` Russell King - ARM Linux
2014-09-04  1:01   ` long.wanglong
2014-09-04  1:01     ` long.wanglong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=540443DA.7030502@huawei.com \
    --to=long.wanglong@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.