On 05/06/2016 02:48 PM, Thomas Gleixner wrote:
> On Fri, 6 May 2016, Joseph Salisbury wrote:
>> A kernel bug report was opened against Ubuntu [0]. After a kernel
>> bisect, it was found that reverting the following commit resolved this bug:
>>
>> commit 1f12e32f4cd5243ae46d8b933181be0d022c6793
>> Author: Thomas Gleixner <email address hidden>
>> Date: Mon Feb 22 22:19:15 2016 +0000
>>
>> x86/topology: Create logical package id
>>
>> To build successfully with this commit reverted, I also had to revert
>> commits: e7ee3e8,2d4de83,87f01cc and 33c3cc7.
>>
>> The regression was introduced as of v4.6-rc1.
>>
>> I was hoping to get your feedback, since you are the patch author. Do
>> you think gathering any additional data will help diagnose this issue,
>> or would it be best to submit a revert request?
> Yuck. That dies with a divide error. And that looks like XEN is supplying crap
> data in the CPUID.
Joe, do you have
ed6069b xen/apic: Provide Xen-specific version of cpu_present_to_apicid
APIC op
On 05/06/2016 02:48 PM, Thomas Gleixner wrote: ae46d8b933181be 0d022c6793 2d4de83, 87f01cc and 33c3cc7.
> On Fri, 6 May 2016, Joseph Salisbury wrote:
>> A kernel bug report was opened against Ubuntu [0]. After a kernel
>> bisect, it was found that reverting the following commit resolved this bug:
>>
>> commit 1f12e32f4cd5243
>> Author: Thomas Gleixner <email address hidden>
>> Date: Mon Feb 22 22:19:15 2016 +0000
>>
>> x86/topology: Create logical package id
>>
>> To build successfully with this commit reverted, I also had to revert
>> commits: e7ee3e8,
>>
>> The regression was introduced as of v4.6-rc1.
>>
>> I was hoping to get your feedback, since you are the patch author. Do
>> you think gathering any additional data will help diagnose this issue,
>> or would it be best to submit a revert request?
> Yuck. That dies with a divide error. And that looks like XEN is supplying crap
> data in the CPUID.
Joe, do you have
ed6069b xen/apic: Provide Xen-specific version of cpu_present_ to_apicid
APIC op
-boris
> x86/kernel/ smpboot. c x86/kernel/ smpboot. c package_ map( data.x86_ max_cores; "x86_max_ cores == zero !?!?"); packages = DIV_ROUND_ UP(total_ cpus, ncpus);
> Does the patch below cure the issue?
>
> Thanks,
>
> tglx
>
> 8<---------------
>
> --- a/arch/
> +++ b/arch/
> @@ -332,6 +332,11 @@ static void __init smp_init_
> * primary cores.
> */
> ncpus = boot_cpu_
> + if (!ncpus) {
> + pr_warn(
> + ncpus = 1;
> + }
> +
> __max_logical_
>
> /*