All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
Cc: Will Deacon <will.deacon@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Pavel Machek <pavel@ucw.cz>, Mason <slash.tmp@free.fr>,
	Paul Kocialkowski <contact@paulk.fr>,
	Masahiro Yamada <yamada.m@jp.panasonic.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kuznetsovg@dev.rtsoft.ru
Subject: Re: [RFC/PATCH] arm: do not skip SMP init calls on SMP_ON_UP case
Date: Mon, 23 Nov 2015 12:12:16 +0000	[thread overview]
Message-ID: <20151123121216.GO8644@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <5653015C.4020405@dev.rtsoft.ru>

On Mon, Nov 23, 2015 at 03:06:52PM +0300, Nikita Yushchenko wrote:
> 23.11.2015 15:03, Russell King - ARM Linux пишет:
> > On Mon, Nov 23, 2015 at 02:59:06PM +0300, nyushchenko@dev.rtsoft.ru wrote:
> >> From: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
> >>
> >> 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.
> 
> Will try to check mainline (although not sure if that will be possible
> on available custom hardware)

iMX6 is fairly well supported in mainline.  The only reason to use a
custom kernel is if you want to use some feature which mainline does
not support (or support very well) such as video decode, the full IPU
facilities, GPUs or CEC (sorry, I don't have an expansive list.)

The GPU problem for the GC320/GC880/GC2000 is fairly close to being
solved in a functional (but maybe not yet performant) manner.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/PATCH] arm: do not skip SMP init calls on SMP_ON_UP case
Date: Mon, 23 Nov 2015 12:12:16 +0000	[thread overview]
Message-ID: <20151123121216.GO8644@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <5653015C.4020405@dev.rtsoft.ru>

On Mon, Nov 23, 2015 at 03:06:52PM +0300, Nikita Yushchenko wrote:
> 23.11.2015 15:03, Russell King - ARM Linux ?????:
> > On Mon, Nov 23, 2015 at 02:59:06PM +0300, nyushchenko at dev.rtsoft.ru wrote:
> >> From: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
> >>
> >> 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.
> 
> Will try to check mainline (although not sure if that will be possible
> on available custom hardware)

iMX6 is fairly well supported in mainline.  The only reason to use a
custom kernel is if you want to use some feature which mainline does
not support (or support very well) such as video decode, the full IPU
facilities, GPUs or CEC (sorry, I don't have an expansive list.)

The GPU problem for the GC320/GC880/GC2000 is fairly close to being
solved in a functional (but maybe not yet performant) manner.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2015-11-23 12:13 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23 11:59 [RFC/PATCH] arm: do not skip SMP init calls on SMP_ON_UP case nyushchenko
2015-11-23 11:59 ` nyushchenko at dev.rtsoft.ru
2015-11-23 12:03 ` Russell King - ARM Linux
2015-11-23 12:03   ` Russell King - ARM Linux
2015-11-23 12:06   ` Nikita Yushchenko
2015-11-23 12:06     ` Nikita Yushchenko
2015-11-23 12:12     ` Russell King - ARM Linux [this message]
2015-11-23 12:12       ` Russell King - ARM Linux
2015-11-23 12:19       ` Russell King - ARM Linux
2015-11-23 12:19         ` Russell King - ARM Linux
2015-11-23 12:46         ` Nikita Yushchenko
2015-11-23 12:46           ` Nikita Yushchenko
2015-11-23 12:32     ` Vladimir Murzin
2015-11-23 12:32       ` Vladimir Murzin
2015-11-23 12:42       ` Nikita Yushchenko
2015-11-23 12:42         ` Nikita Yushchenko
2015-11-23 12:47         ` Nikita Yushchenko
2015-11-23 12:47           ` Nikita Yushchenko
2015-11-23 13:04           ` Russell King - ARM Linux
2015-11-23 13:04             ` Russell King - ARM Linux
2015-11-24 14:52             ` Nikita Yushchenko
2015-11-24 14:52               ` Nikita Yushchenko
2015-11-24 15:05               ` Nikita Yushchenko
2015-11-24 15:05                 ` Nikita Yushchenko
2015-11-24 15:28                 ` Nikita Yushchenko
2015-11-24 15:28                   ` Nikita Yushchenko
2015-11-24 15:33               ` Russell King - ARM Linux
2015-11-24 15:33                 ` Russell King - ARM Linux
2015-11-28 11:13                 ` Nikita Yushchenko
2015-11-28 11:13                   ` Nikita Yushchenko
2015-11-30  8:25                   ` Nikita Yushchenko
2015-11-30  8:25                     ` Nikita Yushchenko

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=20151123121216.GO8644@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=ard.biesheuvel@linaro.org \
    --cc=contact@paulk.fr \
    --cc=ian.campbell@citrix.com \
    --cc=kuznetsovg@dev.rtsoft.ru \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nyushchenko@dev.rtsoft.ru \
    --cc=pavel@ucw.cz \
    --cc=robh@kernel.org \
    --cc=slash.tmp@free.fr \
    --cc=will.deacon@arm.com \
    --cc=yamada.m@jp.panasonic.com \
    /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.