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

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

[Wang Long]

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 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?


-- 
1.7.9.5

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

[Wang Long]

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 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?


-- 
1.7.9.5

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

[long.wanglong]

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?
> 
> 

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

[long.wanglong]

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?
> 
> 

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

[Arnd Bergmann]

On Monday 01 September 2014 18:00:58 long.wanglong wrote:
> 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 see.

I'm looking at the code more closely now:

> > 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;

This test basically checks whether the __fixup_smp_on_up code was
run or not. This has changed in bc41b8724f24 "ARM: 7846/1: Update
SMP_ON_UP code to detect A9MPCore with 1 CPU devices", in order
to support a quirk in the Aegis platform. Can you try reverting
that commit?

	Arnd

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

[Arnd Bergmann]

On Monday 01 September 2014 18:00:58 long.wanglong wrote:
> 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 see.

I'm looking at the code more closely now:

> > 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;

This test basically checks whether the __fixup_smp_on_up code was
run or not. This has changed in bc41b8724f24 "ARM: 7846/1: Update
SMP_ON_UP code to detect A9MPCore with 1 CPU devices", in order
to support a quirk in the Aegis platform. Can you try reverting
that commit?

	Arnd

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

[long.wanglong]

On 2014/9/1 18:26, Arnd Bergmann wrote:
> On Monday 01 September 2014 18:00:58 long.wanglong wrote:
>> 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 see.
> 
> I'm looking at the code more closely now:
> 
>>> 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;
> 
> This test basically checks whether the __fixup_smp_on_up code was
> run or not. This has changed in bc41b8724f24 "ARM: 7846/1: Update
> SMP_ON_UP code to detect A9MPCore with 1 CPU devices", in order
> to support a quirk in the Aegis platform. Can you try reverting
> that commit?
> 
> 	Arnd
> 
> .
> 


Hi Arnd

When i revert the commit bc41b8724f24, the secondary core can boot.
The problem is that qemu doesn't provide emulation of the SCU base
address register. When reading the SCU base, qemu just return 0.

In the real hardware, there is no this problem.

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

[long.wanglong]

On 2014/9/1 18:26, Arnd Bergmann wrote:
> On Monday 01 September 2014 18:00:58 long.wanglong wrote:
>> 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 see.
> 
> I'm looking at the code more closely now:
> 
>>> 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;
> 
> This test basically checks whether the __fixup_smp_on_up code was
> run or not. This has changed in bc41b8724f24 "ARM: 7846/1: Update
> SMP_ON_UP code to detect A9MPCore with 1 CPU devices", in order
> to support a quirk in the Aegis platform. Can you try reverting
> that commit?
> 
> 	Arnd
> 
> .
> 


Hi Arnd

When i revert the commit bc41b8724f24, the secondary core can boot.
The problem is that qemu doesn't provide emulation of the SCU base
address register. When reading the SCU base, qemu just return 0.

In the real hardware, there is no this problem.

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

[Peter Maydell]

On 4 September 2014 02:13, long.wanglong <long.wanglong@huawei.com> wrote:
> When i revert the commit bc41b8724f24, the secondary core can boot.
> The problem is that qemu doesn't provide emulation of the SCU base
> address register. When reading the SCU base, qemu just return 0.

You need to upgrade your QEMU -- we improved the emulation
of all our Cortex-A9 boards to make sure they set valid values
for the base address register, in order to fix exactly this regression.
QEMU 2.0 or later should work.

(As an aside, I think the Aegis quirk test is pretty ugly:
"base address happens to be set to zero" is not exactly
a very reliable way to identify a particular SoC. However
in this case QEMU was emulating real h/w insufficiently
accurately, so we fixed it.)

thanks
-- PMM

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

[Peter Maydell]

On 4 September 2014 02:13, long.wanglong <long.wanglong@huawei.com> wrote:
> When i revert the commit bc41b8724f24, the secondary core can boot.
> The problem is that qemu doesn't provide emulation of the SCU base
> address register. When reading the SCU base, qemu just return 0.

You need to upgrade your QEMU -- we improved the emulation
of all our Cortex-A9 boards to make sure they set valid values
for the base address register, in order to fix exactly this regression.
QEMU 2.0 or later should work.

(As an aside, I think the Aegis quirk test is pretty ugly:
"base address happens to be set to zero" is not exactly
a very reliable way to identify a particular SoC. However
in this case QEMU was emulating real h/w insufficiently
accurately, so we fixed it.)

thanks
-- PMM

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

[Wang Long]

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 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?


-- 
1.7.9.5

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

[Wang Long]

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 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?


-- 
1.7.9.5

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

[Leon Yu]

On 2014-09-01, Wang Long <long.wanglong@huawei.com> 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 kernel3.17-rc2 ? 

Update qemu to at least 2.0.

qemu of older version fails to smp-boot Linux 3.12+ with CONFIG_SMP_ON_UP
enabled.

-Leon

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

[Wang Long]

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 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?


-- 
1.7.9.5

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

[Wang Long]

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 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?


-- 
1.7.9.5

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

[Arnd Bergmann]

On Monday 01 September 2014 19:35:34 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 write the following patch to test the return value of is_smp().
> 

Can you check the value of CONFIG_SMP?

CONFIG_HAVE_SMP is set by platforms that allow enabling SMP, but you
still have the choice to set CONFIG_SMP on or off.

	Arnd

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

[Arnd Bergmann]

On Monday 01 September 2014 19:35:34 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 write the following patch to test the return value of is_smp().
> 

Can you check the value of CONFIG_SMP?

CONFIG_HAVE_SMP is set by platforms that allow enabling SMP, but you
still have the choice to set CONFIG_SMP on or off.

	Arnd

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

[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.

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

[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.

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

[long.wanglong]

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.

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

[long.wanglong]

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.