From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752610AbbJPCDn (ORCPT ); Thu, 15 Oct 2015 22:03:43 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:44609 "EHLO ironport2-out.teksavvy.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751380AbbJPCDm convert rfc822-to-8bit (ORCPT ); Thu, 15 Oct 2015 22:03:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJCAA731xV/9mBCkxchgOBXcgYAoF5EAEBAQEBAQGBCoQjAQEDASNWBQsFDwUMAhgOAgI9GgYbCYgEDwirDKQXAQEIAQEBAR6BIYoZhQUHgmiBRQEElA6WbYoJI2GDM4MaAQEB X-IPAS-Result: A0AJCAA731xV/9mBCkxchgOBXcgYAoF5EAEBAQEBAQGBCoQjAQEDASNWBQsFDwUMAhgOAgI9GgYbCYgEDwirDKQXAQEIAQEBAR6BIYoZhQUHgmiBRQEElA6WbYoJI2GDM4MaAQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="169714412" Date: Thu, 15 Oct 2015 22:03:38 -0400 To: "Donald Parsons" , "Brown, Len" Cc: linux-kernel@vger.kernel.org From: shrybman Subject: Re[6]: 3.4-rc smpboot: do_boot_cpu failed(-1) to wakeup CPU#1 Message-ID: <0c5a4ca9d877c3d5b5ed57b96bfc0532@teksavvy.com> X-Mailer: IceWarp Mailer 11.2.1.1 x64-Desktop In-Reply-To: <1A7043D5F58CCB44A599DFD55ED4C9484693815B@fmsmsx115.amr.corp.intel.com> References: <505f039bc185286b1295600807741499@teksavvy.com> <1444850729.6312.7.camel@falcon.homelinux.org> <410706506d73adeefedf5b6b21dcc6af@teksavvy.com> <1A7043D5F58CCB44A599DFD55ED4C9484693770E@fmsmsx115.amr.corp.intel.com> <1A7043D5F58CCB44A599DFD55ED4C9484693803A@fmsmsx115.amr.corp.intel.com> <8a2fbe014542329c06e09d7747faf50d@teksavvy.com> <1A7043D5F58CCB44A599DFD55ED4C9484693815B@fmsmsx115.amr.corp.intel.com> X-Priority: 3 MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > try booting upstream with "cpu_init_udelay=1". > If it works, then it actually implicates this commit: > > a9bcaa02a5104ace6a9d9e4a9cd9192a9e7744d6 > ("x86/smpboot: Remove SIPI delays from cpu_up()") > > Unfortunately the commit message for that on is erroneous -- > "cpu_init_udelay=10000" is actually a NO-OP, > because that matches the compiled-in default. > Indeed, any non-zero value bug 10000 should work. That does seem to work. Heh, I tried that with 10000 last week. Thanks, Shane