Vivek Goyal <vgoyal at redhat.com> writes: > Hi Hatayama, > > So what information should I look for to prepare disable_cpu_apic=X in > kdump script? > > Is BSP processor info exported to user space somewhere? Or assuming that > processor 0 is BSP and corresponding apicid should be disabled in kdump > kernel is good enough? On x86 assuming that processor 0 is BSP should be good enough. Unless we starting getting SMP BIOSen playing games with us. > I am looking at /proc/cpuinfo and following 3 fields seem interesting. > > processor: 0 > apicid : 0 > initial apicid : 0 > > What's the difference between apicid and "initial apicid". I guess > initial apicid reflects the apicid number as set by firmware and then > kernel can overwrite it and new number would be reflected in "apicid"? Last I was current initial apicid is the apic id the hardware chooses and it tells you something about the topology of the processors in the system. The apicid is programmed by the BIOS so that the BSP can have apicid 0, and apicid's can be contiguous etc. In principle any piece of software can program apicids but there is no advantage. > If that's the case, then I guess we should be looking at "apicid" of > processor "0" and set that in disable_cpu_apic? Because that's the > number kdump kernel boot should see in apic upon boot. Restricting this to x86 and not Voyager that is correct. Linux cpu 0 is the processor we booted up on as is apparent lots of things special case the bootstrap processor so using a cpu hotplug remove to make it go away is silly. Still to handle cazy cpu hotplug I would recomend to simply force a single cpu if you can't find cpu 0. Eric
