Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753119AbbKWNFN (ORCPT ); Mon, 23 Nov 2015 08:05:13 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:49915 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752093AbbKWNFL (ORCPT ); Mon, 23 Nov 2015 08:05:11 -0500 Date: Mon, 23 Nov 2015 13:04:24 +0000 From: Russell King - ARM Linux To: Nikita Yushchenko Cc: Vladimir Murzin , kuznetsovg@dev.rtsoft.ru, Ian Campbell , Mason , Ard Biesheuvel , Will Deacon , Paul Kocialkowski , linux-kernel@vger.kernel.org, Masahiro Yamada , Pavel Machek , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC/PATCH] arm: do not skip SMP init calls on SMP_ON_UP case Message-ID: <20151123130424.GQ8644@n2100.arm.linux.org.uk> References: <1448279946-19975-1-git-send-email-nyushchenko@dev.rtsoft.ru> <20151123120317.GN8644@n2100.arm.linux.org.uk> <5653015C.4020405@dev.rtsoft.ru> <56530769.4030403@arm.com> <5653099A.7020604@dev.rtsoft.ru> <56530AE6.2060407@dev.rtsoft.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56530AE6.2060407@dev.rtsoft.ru> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2421 Lines: 63 On Mon, Nov 23, 2015 at 03:47:34PM +0300, Nikita Yushchenko wrote: > >>>>> While running an imx6s boasrd, I got following message in boot log: > >>>>> > >>>>> [ 0.032414] CPU1: failed to boot: -38 > >>>>> > >>>>> This looked strange: imx6s is singe-core and kernel perfectly knows > >>>>> that. However, for some reason it tries to initialize CPU 1? > >>>>> > >>>>> I found this to be caused by > >>>>> - CONFIG_SMP_ON_UP successfully detects that system is single core, > >>>>> - this causes is_smp() to return false, > >>>>> - this causes setup_arch() to skip smp_init_cpus() call, > >>>>> - this skips board-specific code that sets cpu_possible mask. > >>>> > >>>> Right, so you should end up with the possible and present masks > >>>> containing just one CPU, which should prevent the kernel trying to > >>>> bring any secondary CPUs online. > >>> > >>> Kernel that is running here still tries to init CPU 1 for some reason. > >> > >> I *guess* cpus node [1] in your dts has more than one cpu entry, could > >> you check please? > > > > Indeed looks so: > > > > # ls /proc/device-tree/cpus > > #address-cells #size-cells cpu@0 cpu@1 name > > > > But my custom device tree just includes imx6dl.dtsi > > > > So it is imx6dl.dtsi in linux-imx tree broken?.. > > Just booted mainline... unline linux-imx, it does not try to init cpu1. > > However, imx6dl.dtsi from mainline also has both cpu@0 and cpu@1 > > So missing piece in linux-imx is elsewhere :( It works as you mentioned - and it relies upon the code you tried to modify. The early boot code detects that the boot CPU is not SMP capable, so through SMP_ON_UP, it "turns off" SMP support by fixing up the code and making is_smp() return false. This prevents smp_init_cpus() being called, which in turn prevents imx_smp_init_cpus() executing, which prevents the CPU possible mask including any CPU but the boot CPU. As only the boot CPU is possible, this prevents the SMP code trying to bring any secondary CPUs online. Applying your patch which removes the is_smp() check will break this logic. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/