(2013/11/12 4:54), H. Peter Anvin wrote:
On 10/12/2013 10:42 AM, Ingo Molnar wrote:* H. Peter Anvin <hpa@xxxxxxxxx> wrote:On 10/09/2013 04:16 PM, tip-bot for HATAYAMA Daisuke wrote:Commit-ID: 1d79e607332d67d9132c176d99b5e7fabe1b6b7f Gitweb: http://git.kernel.org/tip/1d79e607332d67d9132c176d99b5e7fabe1b6b7f Author: HATAYAMA Daisuke <d.hatayama@xxxxxxxxxxxxxx> AuthorDate: Thu, 29 Aug 2013 18:28:04 +0900 Committer: H. Peter Anvin <hpa@xxxxxxxxxxxxxxx> CommitDate: Wed, 9 Oct 2013 15:41:11 -0700 x86, apic: Disable BSP if boot cpu is APThis patch seems to trigger build failures in some configurations. Specifically: (.init.text+0x1307): undefined reference to `boot_cpu_is_bsp_init' Unfortunately I don't have the specific configuration which triggers the failure, as this was discovered by Fengguang's robot.I have triggered that too and have such a config, it's attached.Okay, thinking about this again, this patchset is in fact broken on: 1. Any configuration which has CONFIG_SMP=n and CONFIG_X86_UP_APIC=n. This is a built-time problem. 2. Any CPU which is old enough that MSR_IA32_APICBASE doesn't exist. This is a fatal runtime bug. 3. Any clustered solution which involves a third-party cluster controller such that MSR_IA32_APICBASE may not reflect the reality of the system. This is a less critical issue as "all" it ought to make happen is to disable some CPUs which didn't need it. Hatayama-san, you got this build bug report almost a month ago. It looks like it is going to need a fair bit of cleanup, so I fear this is going to be dropped for v3.13. -hpa
Thanks for pointing out that. I think the first two issues has already been fixed in v3 version. I've just posted v5 version a little time ago. BTW, I changed the basic design at v4 where we specify the initial APIC ID of the processor we want to disable in the kdump 2nd kernel from the the 1st kernel through newly introduced disable_cpu_apicid kernel parameter; it might be similar to the idea you described in the patch description of tip tree. I don't know the third issue. Could you explain what kind of things can happen on clustered system? Only IA32_APIC_BASE MSR is no longer trusted? Or are there other things we can possibly no longer trust? Also, could you explain what you suggest to deal with the issue in more detail? -- Thanks. HATAYAMA, Daisuke -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html