From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755841AbcBVU4Z (ORCPT ); Mon, 22 Feb 2016 15:56:25 -0500 Received: from mail-pa0-f43.google.com ([209.85.220.43]:34283 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755822AbcBVU4X (ORCPT ); Mon, 22 Feb 2016 15:56:23 -0500 Message-ID: <56CB75F4.9080201@gmail.com> Date: Mon, 22 Feb 2016 12:56:20 -0800 From: David Daney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yang Shi CC: Aaro Koskinen , david.daney@cavium.com, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: 4.5-rc4 kernel is failed to bootup on CN6880 References: <56C7BD89.2040800@windriver.com> <20160222124303.GR22974@ak-desktop.emea.nsn-net.net> <56CB5E63.1080005@windriver.com> In-Reply-To: <56CB5E63.1080005@windriver.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/22/2016 11:15 AM, Yang Shi wrote: > On 2/22/2016 4:43 AM, Aaro Koskinen wrote: >> 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? > > Thanks. I did have 48 NR_CPUS set. It works when I changed it to 32. > > I think the problem is core_mask is 32 bit. But when NR_CPUS > 32, in > "core_mask & (1 << id)" core_mask will be sign extended, then the > statement will return non-zero all the time. > That is correct, and perhaps not coincidentally, the reason I have already submitted patches to fix this. David. > Yang > >> >> A. >> > >