Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932187AbcKLWGG (ORCPT ); Sat, 12 Nov 2016 17:06:06 -0500 Received: from aibo.runbox.com ([91.220.196.211]:49418 "EHLO aibo.runbox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750825AbcKLWGF (ORCPT ); Sat, 12 Nov 2016 17:06:05 -0500 From: "M. Vefa Bicakci" Subject: Re: [PATCH] x86/cpuid: Deal with broken firmware once more To: "Charles (Chas) Williams" References: <20161102122557.qs4rl6mb7n7l7j7p@linutronix.de> <24e69019-60d0-29e7-e31f-c6f00f9ed98a@brocade.com> <58e229e2-91f4-a97f-1b9f-089f48ef994a@brocade.com> <86609338-2b45-ed7e-fb07-99421e43a2f1@brocade.com> <49fe8cc5-0f0f-6cac-7a5c-803e81f5667d@runbox.com> Cc: Thomas Gleixner , Sebastian Andrzej Siewior , "x86@kernel.org" , LKML , Peter Zijlstra , Borislav Petkov Message-ID: Date: Sun, 13 Nov 2016 01:05:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1706 Lines: 47 On 11/10/2016 01:50 PM, Charles (Chas) Williams wrote: > > > On 11/09/2016 10:57 PM, M. Vefa Bicakci wrote: >> [ 0.002000] mvb: CPU: Physical Processor ID: 0 >> [ 0.002000] mvb: CPU: Processor Core ID: 0 >> [ 0.002000] mvb: identify_cpu:1112: c: ffff880013b0a040, >> c->logical_proc_id: 65535 >> [ 0.002000] mvb: __default_cpu_present_to_apicid:612: Returning >> 65535! mps_cpu: 1, nr_cpu_ids: 2, cpu_present(mps_cpu): 1 >> [ 0.002000] smpboot: mvb: topology_update_package_map:270: cpu: 1, >> pkg: 4095 >> [ 0.002000] smpboot: APIC(ffff) Converting physical 4095 to logical >> package 0 >> [ 0.002000] smpboot: mvb: topology_update_package_map:305: cpu: 1, >> cpu_data(cpu).logical_proc_id: 0 > > This seems strange. 0xffff is BAD_APICID. Why didn't this fail here: > > for_each_present_cpu(cpu) { > unsigned int apicid = apic->cpu_present_to_apicid(cpu); > > if (apicid == BAD_APICID || > !apic->apic_id_valid(apicid)) <<<<<<<<<< > continue; > if (!topology_update_package_map(apicid, cpu)) > continue; > > topology_update_package_map() should never have been called? (Sorry for the delay!) It appears that this is a different call path than the one in smp_init_package_map function. I *think* the following call path is the one shown in the dmesg, but I am not sure: cpu_bringup_and_idle cpu_bringup (arch/x86/xen/smp.c) smp_store_cpu_info (this call path branch is included for context) identify_secondary_cpu identify_cpu detect_ht topology_update_package_map Sorry about the potentially misleading dmesg excerpt I posted. Vefa