[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion
>>> On 21.11.15 at 02:21, <eswierk@xxxxxxxxxxxxxxxxxx> wrote: > The problem is that the index of the socket_cpumask array is derived via > cpu_to_socket() from the APIC ID of the processor in a given socket, but > the size of the array is computed based on nr_sockets, which is not > necessarily equal to the maximum APIC ID. > > Sizing the socket_cpumask to MAX_APICS rather than nr_sockets seems safer, > though a bit wasteful. I verified that this change fixes the boot crash > with 4 or 8 CPUs on VMware Fusion. But that raises the question of sanity of the CPUID output Xen gets presented: With > (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > (XEN) Processor #0 6:6 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) > (XEN) Processor #2 6:6 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) > (XEN) Processor #4 6:6 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled) > (XEN) Processor #6 6:6 APIC version 21 and taking the output you added, I can only suspect that the value used for determining the socket shift is unexpected (CPUID leaf 0xb). Could you supply the observed values? (See detect_extended_topology() and set_nr_sockets().) As you can see, the core IDs ("CPU: Physical Processor ID: ...") aren't sequential, which we expect them to be (with holes left only when non-power-of-2 values need taking care of). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |