From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754797AbcBVMnh (ORCPT ); Mon, 22 Feb 2016 07:43:37 -0500 Received: from demumfd002.nsn-inter.net ([93.183.12.31]:57516 "EHLO demumfd002.nsn-inter.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751809AbcBVMne (ORCPT ); Mon, 22 Feb 2016 07:43:34 -0500 Date: Mon, 22 Feb 2016 14:43:03 +0200 From: Aaro Koskinen To: Yang Shi , david.daney@cavium.com Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: 4.5-rc4 kernel is failed to bootup on CN6880 Message-ID: <20160222124303.GR22974@ak-desktop.emea.nsn-net.net> References: <56C7BD89.2040800@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C7BD89.2040800@windriver.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1334 X-purgate-ID: 151667::1456145005-00004E94-CE82AB39/0/0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Fri, Feb 19, 2016 at 05:12:41PM -0800, Yang Shi wrote: > I tried to boot 4.5-rc4 kernel on my CN6880 board, but it is failed at > booting up secondary cores. The error is: With v4.5-rc5, EBB6800 is booting fine: [ 0.000000] CPU0 revision is: 000d9108 (Cavium Octeon II) [...] [ 2286.273935] SMP: Booting CPU01 (CoreId 1)... [ 2286.278201] CPU1 revision is: 000d9108 (Cavium Octeon II) [...] [ 2287.214953] SMP: Booting CPU31 (CoreId 31)... [ 2287.224668] CPU31 revision is: 000d9108 (Cavium Octeon II) [ 2287.224865] Brought up 32 CPUs > CPU31 revision is: 000d9101 (Cavium Octeon II) > SMP: Booting CPU32 (CoreId 32)... > Secondary boot timeout > > I passed "numcores=32" in kernel commandline since there are 32 cores ion > CN6880. You shouldn't have CPU32 in that case, the numbering starts from zero. Also the coremask is 32-bit. I can reproduce your issue with CONFIG_NR_CPUS=64. Possibly this code is incorrect for NR_CPUS bigger than 32: /* The present CPUs get the lowest CPU numbers. */ cpus = 1; for (id = 0; id < NR_CPUS; id++) { if ((id != coreid) && (core_mask & (1 << id))) { set_cpu_possible(cpus, true); set_cpu_present(cpus, true); What CONFIG_NR_CPUS did you use? A.